Miguel Armas
2003-May-03 03:31 UTC
[Shorewall-users] "shorewall add" and hosts not exactly the same?
Hi all! I''ve been trying to setup a dynamic shorewall configuration and I''m having problems with "shorewall add" because it seems it doesn''t work like defining the host in the hosts file... What I''m trying to do is to control client''s access from a semi-public network to the Internet. Here is my configuration: ** interfaces: net wlan0 detect dhcp,routefilter loc eth1 detect dhcp - eth0 detect dhcp My external inteface is a wireless link and the public network is attached to eth0 ** zones: net Net Internet loc Local Local networks auth Authenticated Authenticated Clients pub Public Public Network The pub zone is the default zone for the public network, I have a DHCP server for configuring the clients. The auth zone is where I will assign the authenticated clients to allow Internet acess ** hosts: pub eth0:192.168.254.0/24 auth eth0:192.168.254.21/32 These are te definitions for hosts: by default all clients belong to pub zone, when a client authenticates (via Web) I add it to the auth zone ** policy: fw all ACCEPT loc net ACCEPT loc fw ACCEPT auth net CONTINUE auth fw CONTINUE pub net ACCEPT info pub fw ACCEPT info net all DROP info all all REJECT info I accept traffic from both zones (pub,auth) to net and fw ** rules: ACCEPT net fw tcp ssh,www,domain ACCEPT net fw udp ntp,domain ACCEPT net fw icmp 8 ACCEPT auth fw tcp ssh,www,domain ACCEPT auth fw udp ntp,domain ACCEPT auth fw icmp 8 ACCEPT pub fw tcp ssh,www,domain ACCEPT pub fw udp ntp,domain ACCEPT pub fw icmp 8 DNAT pub!auth fw:192.168.254.1 all - - !192.168.254.1 This is the interesting part. The idea is that when a user connects to the network, it''s included in the pub zone. All the traffic in this zone is redirected to the firewall, where I have a web page describing how to register with the service (I''ll probably use NoCatAuth). When the user is authenticated by my auth service, I''ll run: shorewall add eth0:ip.addr.of.client auth And then the client will be able to access the internet. My problem is that everything works perfectly when I define a client''s IP address in the hosts file, but when I define it dynamically with "shorewall add", the firewall keeps DNAT''ing the traffic to the firewall. My questions are: are hosts definitions and "shorewall add" supposed to work exactly the same? do they have the same precedence? do I have a config error someplace that only triggers when I use "shorewall add"? I?m running 2.4.18-18.8.0 stock redhat''s kernel with shorewall 1.4.2. Salu2! BTW Tom, thanks for this GREAT tool, I used to use my own firewall script and was thinking about adding a more features until I discovered Shorewall. It has all I wanted to add to my script, and a lot more ;) -- -------------------------------------- Miguel Armas <kuko@maarmas.com> Consultor de Sistemas y Comunicaciones Ing. Tec. de Telecomunicaciones --------------------------------------
Tom Eastep
2003-May-03 06:30 UTC
[Shorewall-users] "shorewall add" and hosts not exactly the same?
On Sat, 3 May 2003 11:29:46 +0100, Miguel Armas <kuko@maarmas.com> wrote:> > My problem is that everything works perfectly when I define a client''s IP > address in the hosts file, but when I define it dynamically with > "shorewall add", the firewall keeps DNAT''ing the traffic to the firewall.Miguel -- maybe the phrase "keeps DNAT''ing the traffic to the firewall" has meaning for you but I have absolutely no idea what you mean. Please: a) "shorewall clear" b) Add a client to your "auth" zone using your login script. c) Try to access the internet d) "shorewall status > /tmp/status.txt" Forward the /tmp/status.txt file as an attachment and explain what you think is happening.> > My questions are: are hosts definitions and "shorewall add" supposed to > work exactly the same?They will not generate exactly the same ruleset, no. Do they have the same precedence? Probably not.> I have a config error someplace that only triggers when I use "shorewall > add"?Hopefully. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ teastep@shorewall.net
Tom Eastep
2003-May-03 06:38 UTC
[Shorewall-users] "shorewall add" and hosts not exactly the same?
On Sat, 03 May 2003 06:29:43 -0700, Tom Eastep <teastep@shorewall.net> wrote:> Please: > > a) "shorewall clear"Duh -- haven''t had my coffee yet this morning. Make that "shorewall reset" -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ teastep@shorewall.net
Miguel Armas
2003-May-03 08:29 UTC
[Shorewall-users] "shorewall add" and hosts not exactly the same?
On Saturday 03 May 2003 14:29, Tom Eastep wrote:> On Sat, 3 May 2003 11:29:46 +0100, Miguel Armas <kuko@maarmas.com> wrote: > > My problem is that everything works perfectly when I define a client''s IP > > address in the hosts file, but when I define it dynamically with > > "shorewall add", the firewall keeps DNAT''ing the traffic to the firewall. > > Miguel -- maybe the phrase "keeps DNAT''ing the traffic to the firewall" has > meaning for you but I have absolutely no idea what you mean. Please:Well, sorry for my english ;-|. I ment that the exception in: DNAT pub!auth fw:192.168.254.1 all - - !192.168.254.1 isn''t working. The firewall apply this rule for the hosts I add to the auth zone with "shorewall add eth0:host auth" This rule shouldn''t apply after I "shorewall add" a host, just as it doesn''t apply when I define the host in hosts file.> a) "shorewall clear" > b) Add a client to your "auth" zone using your login script. > c) Try to access the internet > d) "shorewall status > /tmp/status.txt" > > Forward the /tmp/status.txt file as an attachment and explain what you > think is happening.After I sent my first message I''ve been watching the differences and I think I found the problem: It seems that the rule: DNAT pub!auth fw:192.168.254.1 all - - !192.168.254.1 creates the following NAT tables: 1. With 192.168.254.21 assigned to the zone auth in the hosts file -- Chain PREROUTING (policy ACCEPT) target prot opt source destination pub_dnat all -- 192.168.254.0/24 anywhere Chain POSTROUTING (policy ACCEPT) target prot opt source destination wlan0_masq all -- anywhere anywhere Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain nonat1 (1 references) target prot opt source destination RETURN all -- 192.168.254.21 !192.168.254.1 DNAT all -- anywhere !192.168.254.1 to:192.168.254.1 Chain pub_dnat (1 references) target prot opt source destination nonat1 all -- anywhere anywhere Chain wlan0_masq (1 references) target prot opt source destination MASQUERADE all -- 192.168.254.0/24 anywhere -- So, for pub_dnat, it first jumps to nonat1 to skip the exceptions. This one works... 2. If I try to assign another host to the auth zone with "shorewall add" these rules doesn''t change, so nonat1 doesn''t catch the new host and the DNAT applies... In the firewall script I found a function called add_to_zone() with the following code: ... # If the zone passed in the command has a dnat chain then insert a rule in # the nat table PREROUTING chain to jump to that chain when the source # matches the new host(s) # chain=${zone}_dnat if nat_chain_exists $chain; then do_iptables -t nat -I PREROUTING -i $interface -s $host -j $chain fi ... So the code can handle DNAT rules to dynamically added hosts, but not the exception to DNAT rules?? Maybe it should create a nonat table with the name of the zone (auth_nonat1) and add a RETURN rule to that table with the newly added host?? Is it very complex to implement? Salu2! -- -------------------------------------- Miguel Armas <kuko@maarmas.com> Consultor de Sistemas y Comunicaciones Ing. Tec. de Telecomunicaciones --------------------------------------
Tom Eastep
2003-May-03 08:38 UTC
[Shorewall-users] "shorewall add" and hosts not exactly the same?
On Sat, 3 May 2003 16:28:13 +0100, Miguel Armas <kuko@maarmas.com> wrote:> DNAT pub!auth fw:192.168.254.1 all - - !192.168.254.1That rule is statically created at "shorewall [re]start" and is not changed when you add hosts to the ''auth'' zone.> > So the code can handle DNAT rules to dynamically added hosts, but not the > exception to DNAT rules??That''s correct.> > Maybe it should create a nonat table with the name of the zone > (auth_nonat1) > and add a RETURN rule to that table with the newly added host?? > Is it very complex to implement?Let me give it some thought... -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ teastep@shorewall.net
Tom Eastep
2003-May-03 09:45 UTC
[Shorewall-users] "shorewall add" and hosts not exactly the same?
On Sat, 03 May 2003 08:38:03 -0700, Tom Eastep <teastep@shorewall.net> wrote:> On Sat, 3 May 2003 16:28:13 +0100, Miguel Armas <kuko@maarmas.com> wrote:> >> >> Maybe it should create a nonat table with the name of the zone >> (auth_nonat1) >> and add a RETURN rule to that table with the newly added host?? >> Is it very complex to implement? > > Let me give it some thought... >In general, we can''t name the exclude chain with the name of a single zone because multiple zones can be excluded: DNAT Z1:!Z2,Z3,Z4 Even if we make a special case when the exclude list has a single zone, we still have to remember all of the details about the DNAT rule in order to add the correct RETURN rule. Rather than using dynamic zones, you could have your DNAT rule as: DNAT pub fw:192.168.254.1 all - - !192.168.254.1 When you want to enable access for $host: iptables -I pub_dnat -s $host -j RETURN and when you want to disable access for $host: iptables -D pub_dnat -s $host -j RETURN -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ teastep@shorewall.net
Miguel Armas
2003-May-03 10:18 UTC
[Shorewall-users] "shorewall add" and hosts not exactly the same?
On Saturday 03 May 2003 17:45, you wrote:> On Sat, 03 May 2003 08:38:03 -0700, Tom Eastep <teastep@shorewall.net> > > wrote: > > On Sat, 3 May 2003 16:28:13 +0100, Miguel Armas <kuko@maarmas.com> wrote: > >> Maybe it should create a nonat table with the name of the zone > >> (auth_nonat1) > >> and add a RETURN rule to that table with the newly added host?? > >> Is it very complex to implement? > > > > Let me give it some thought...Wow!! ever heard of fanatical support?? ;-)> In general, we can''t name the exclude chain with the name of a single zone > because multiple zones can be excluded: > > DNAT Z1:!Z2,Z3,Z4Yes, I was messing with the idea and already had a preliminary patch (attached). I was trying to create a ${zone}_nonat${seq} for the exceptions, but I just tried the previous line and it didn''t work...> Even if we make a special case when the exclude list has a single zone, we > still have to remember all of the details about the DNAT rule in order to > add the correct RETURN rule.That was another problem with my patch, my next try was going to be applying the conditions to the pub_dnat chain to jump to the nonat chain> Rather than using dynamic zones, you could have your DNAT rule as: > > DNAT pub fw:192.168.254.1 all - - !192.168.254.1 > > When you want to enable access for $host: > > iptables -I pub_dnat -s $host -j RETURN > > and when you want to disable access for $host: > > iptables -D pub_dnat -s $host -j RETURNYeah, I guess this is MUCH simpler, and works ;-) Thanks a lot! Salu2! -- -------------------------------------- Miguel Armas <kuko@maarmas.com> Consultor de Sistemas y Comunicaciones Ing. Tec. de Telecomunicaciones -------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: shorewall.patch Type: text/x-diff Size: 1896 bytes Desc: not available Url : http://lists.shorewall.net/pipermail/shorewall-users/attachments/20030503/dd854d4c/shorewall.bin