Hi Tom, Just an update on the issue I've been experiencing. I tried with conntrack and with the -p in the STARTOPTIONS, but I think the issue isn't related to this as the dump was suggesting. I've attached a two dumps, sorry if that too much info. The first dump was taken when chilli and shorewall were working well together(no Sfilter messages), and the second dump was taken when chilli and shorewall weren't working well together (sfilter messages for both tcp/80 and udp53).
The sequence I've identified is this, and its only when I have Providers configured in Shorewall: 1) Chilli and Shorewall working well together 2) Client connects to Chilli on tun10 and gets IP address of 192.168.200.10, and is able to browse the internet 3) I reboot the appliance 4) Shorewall service starts (two Providers(VSAT and FB) configured, tun10 defined in interfaces/zones) 5) Chilli service starts 6) Clients connects to Chilli on tun10 and gets IP address of 192.168.200.10, and is not able to DNS resolve or browse the internet. 7) Shorewall starts reporting sFilter messages for udp/53 and http/80 I can get this to work by either: a) # shorewall restart b) # shorewall safe-restart (and click either Y or N, as both work) c) Change the service start order in Centos, so Chilli starts before Shorewall So, the issue is caused when Chilli is started after Shorewall. The tun10 interface does not exist before Chilli starts, so from the dumps, it looks like Shorewall doesn't populate the tun10 subnet into the Providers routing tables. So, where to from here? I could force shorewall to restart everytime Chilli starts, but that's not desirable. Or I could leave the service start order as Chilli, then Shorewall. But if Chilli crashes, then I would need to restart the process and then restart Shorewall. I'm curious to know what part of the # shorewall safe-restart gets this to work, even if I select 'N' to not accept the new configuration, it still fixes the issue. Best Regards, Nigel -----Original Message----- From: Nigel Quinn Sent: 07 January 2016 08:28 To: [email protected] Subject: RE: [Shorewall-users] Shorewall SFILTER issue with CoovaChilli configuration Hi Tom, Thanks for the suggestion, and for the clarifications. I have conntrack installed on the server and will try with the -p in the STARTOPTIONS, and also try and pin down the steps that initiate the issue. Nigel -----Original Message----- From: Tom Eastep [mailto:[email protected]] Sent: 24 December 2015 16:51 To: [email protected] Subject: Re: [Shorewall-users] Shorewall SFILTER issue with CoovaChilli configuration On 12/23/2015 09:47 AM, Nigel Quinn wrote: > > So, I have a server, eth0 WAN, eth1 LAN, tun10 is the tun interface > that CoovaChilli puts onto eth1 to capture all user traffic, then > authenticates it against a RADIUS server, and routes authenticated > traffic to eth0 to access the internet. > > The problem I am having is that Shorewall intermittently has issues > with the NATing of packets, so I see lots of SFILTER messages showing > return traffic coming into eth0 to the IP address of PCs on > tun10(192.168.200.0/24). So at times the clients can access the > internet and at other times they can't. So why the SFILTER messages, > if the masq file is configured correctly why is Shorewall not > translating the packets, or keeping track of the translation? First of all, Shorewall neither translates packets nor does it keep track of translations. Shorewall is a tool for configuring various networking facilities within the Linux kernel. It is those facilities that are responsible for translation. The most common cause of the problem you describe happens with UDP; I notice that the 'sfilter' log messages in the dump all refer to UDP. The problem happens because UDP packets are received by your gateway before Shorewall has started (has configured the kernel based on the input that you have provided). This establishes an entry in the conntrack table that does not apply NAT. So, for as long as the client tries to use that stream, the packets sent as part of the stream will not have NAT applied. There are a couple of things that you can do to work around this issue: a) Install and configure Shorewall Init; or b) Install the 'conntrack' utility and configure STARTOPTIONS to include the '-p' option. That way, when Shorewall is started by init, it will purge the conntrack table so that all subsequent UDP packets will create new (natted) conntrack entries. STARTOPTIONS are specified in /etc/sysconfig/shorewall on Centos. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
