> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 03/07/2017 11:33 PM, Simon Matter wrote: >> Hi Tom and all, >> >> Since upgrading from shorewall-5.1.1 to shorewall-5.1.2.1 I have a >> new problem with longstanding TCP connections being killed during >> "shorewall reload". >> >> This has never happened before so I guess it has something to do >> with the new defaults. >> >> An interesting point is that it happens most of the time, but not >> always. Seems it happens more if rules have been changed, which >> probably means it happens more if the reload takes longer to >> complete. >> >> The connection being killed is handled through this rule: DNAT >> net dmz:bb.bb.bb.bb tcp 3217 - cc.cc.cc.cc >> >> Log shows: Mar 8 07:16:02 fw1 kernel: FORWARD REJECT IN=eth2 >> OUT=eth2 SRC=aa.aa.aa.aa DST=bb.bb.bb.bb LEN=52 TOS=0x00 PREC=0x00 >> TTL=55 ID=52512 DF PROTO=TCP SPT=40508 DPT=3217 WINDOW=703 RES=0x00 >> ACK URGP=0 Mar 8 07:16:02 fw1 kernel: FORWARD REJECT IN=eth2 >> OUT=eth2 SRC=aa.aa.aa.aa DST=bb.bb.bb.bb LEN=40 TOS=0x00 PREC=0x00 >> TTL=55 ID=0 DF PROTO=TCP SPT=40508 DPT=3217 WINDOW=0 RES=0x00 RST >> URGP=0 >> >> Do others see similar issues since upgrading to 5.1.2.1? >> > > Hi Simon,
Hi Tom, > You are the first to report this. Is this a Multi-ISP configuration? > This looks like a routing problem; the packet is being routed back out > of eth2 rather than to the DMZ interface. Thanks for taking a look at it! No, it's not a Multi-ISP configuration. Most IP addresses on the internet side are proxyarped to the DMZ. Maybe that explains why the packet is forwarded from eth2 to eth2, while physically it then goes via eth1 to the host in DMZ? I tried to collect some more of the relevant information below: params: NET_IF="eth2" NET_IFOPTIONS="dhcp,routefilter,logmartians,nosmurfs" interfaces: dmz eth1 net $NET_IF $NET_IFOPTIONS policy: fw net ACCEPT net all DROP info all all REJECT info proxyarp: aa.aa.aa.aa eth1 eth2 bb.bb.bb.bb eth1 eth2 mangle: MARK(1) 0.0.0.0/0 0.0.0.0/0 tcp 3217 - - - - Minimize-Delay MARK(1) 0.0.0.0/0 0.0.0.0/0 tcp - 3217 - - - Minimize-Delay > To rule out the new _DEFAULT settings, please switch back to using > Reject and Drop and see of the problem persists. OK, I'll try this tomorrow early in the morning while nobody is working already. I'm wondering if I should set the persistent flag for the entries in proxyarp. But as I understand it should only matter for stop and clear, not reload? Anyway I've reloaded shorewall so many times in the past and it has never terminated any TCP connections - at least not that I'm aware of. Thanks for any insights, Simon ------------------------------------------------------------------------------ Announcing the Oxford Dictionaries API! The API offers world-renowned dictionary content that is easy and intuitive to access. Sign up for an account today to start using our lexical data to power your apps and projects. Get started today and enter our developer competition. http://sdm.link/oxford _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
