Tom Eastep
2010-Jan-18 17:29 UTC
Re: WG: ppp+ port forward from internal to external (FAQ2)
Michael Weickel - iQom Business Services GmbH wrote:> I will make an example for DNS. It runs public on 81.209.168.100 and RFC1918 > on 10.10.10.85. I try to access 81.209.168.100 on port 53 from v516 machine > 10.100.198.1 and the only result I see is this > > ping www.google.de source fasstethernet 0 (where fe0 is 10.100.198.1) > > tcpdump -i vlan516 host 10.100.198.1 > 00:06:03.180204 IP 10.100.198.1.52928 > 81.209.168.100.domain: 17+ A? > www.google.de. (31) >Okay -- I''m assuming that this is an incoming DNS packet on vlan516 addressed to 81.209.168.100? Because if were an outgoing packet, it would have been SNATed to 172.20.20.5. Chain vlan516_masq (1 references) pkts bytes target prot opt in out source destination 0 0 SNAT all -- * * 172.20.20.0/24 0.0.0.0/0 policy match dir out pol none to:172.20.20.5 0 0 SNAT all -- * * 10.100.198.0/24 0.0.0.0/0 policy match dir out pol none to:172.20.20.5 So I''m already lost as to why you would see this packet on this interface. There don''t seem to be any DNAT rules for traffic arriving on vlan516 so the packet remains unmodified. It hits this routing rule: 32722: from all iif vlan516 lookup iqom_test_dns That routing table contains: 10.100.198.0/24 via 172.20.20.2 dev vlan516 default via 217.199.198.153 dev vlan3006 So it is shipped off to 217.199.198.153 through vlan3006 where it is masqueraded.> First of all I tried without using Shorewall FAQ 2b and the result is > exactly as tcpdumped above.I saw no sign of FAQ 2b''s solution in that example. I must be missing something, but then your routing configuration is so complex that it would take a week to understand fully (and I''m not going to spend a week on this...). -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 \________________________________________________ ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world''s best and brightest in the field, creating opportunities for Conference attendees to learn about information security''s most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev
Michael Weickel - iQom Business Services GmbH
2010-Jan-18 23:48 UTC
WG: ppp+ port forward from internal to external (FAQ2)
I´m sorry for the wrong way to post on the list. I´ve setup a test environment and I try to give my best to outline a problem description. My shorewall version is 3.4.8 and my kernel 2.6.31-r6 I have five important interfaces/zones/interface-ip/networks in my environment. vlan200 (phy bond3) v200 10.10.10.20 10.10.10.0/24 vlan664 (phy bond3) v664 172.31.255.2 172.31.255.0/30,10.100.100.0/24 vlan516 (phy bond3) v516 172.20.20.5 172.20.20.0/24,10.100.198.0/24 vlan3003 (phy bond0) v3003 217.199.198.141 217.199.198.136/29,81.209.168.96/28,91.196.143.128/28 vlan3006 (phy bond0) v3008 217.199.198.157 217.199.198.152/29 v200 and v664 accesses the internet by v3003 and v516 accesses the internet by v3006. I have a lot of important web services in v200 which have to be accessible from outside (this means through v3003) and they are by DNAT. In addition I have to ensure that these services are accessible by zones v200, v664 and v516 known by their public dns-names/ips. Regarding v200 and v664 it was an quite easy job by using Shorewall FAQ2. Regarding v516 I thought maybe Shorewall FAQ 2a may help but either I do something wrong or it does not help anyway. I am a bit afraid to say that the affected machine has a lot of different lookup routing tables. In my case only two are relevant - these are table 14 and table 30. Here is the output. ip route show table 30 10.100.198.0/24 via 172.20.20.2 dev vlan516 default via 217.199.198.153 dev vlan3006 ip rule show | grep 30 32718: from 217.199.198.157 lookup 30 32719: from all iif vlan3006 lookup 30 32721: from 172.20.20.5 lookup 30 32722: from all iif vlan516 lookup 30 ip route show table 14 10.100.100.0/24 via 172.31.255.1 dev vlan664 10.10.10.0/24 dev vlan200 scope link src 10.10.10.20 default via 217.199.198.137 dev vlan3003 ip rule show | grep 14 32731: from 10.10.10.0/24 to 10.100.100.0/24 iif vlan200 lookup 14 32733: from 10.10.10.20 to 10.100.100.0/24 lookup 14 32745: from all iif vlan664 lookup 14 32746: from 172.31.255.2 lookup 14 32758: from all iif vlan3003 lookup 14 32759: from 217.199.198.142 lookup 14 32760: from 217.199.198.141 lookup 14 32765: from all iif vlan200 lookup 14 I will make an example for DNS. It runs public on 81.209.168.100 and RFC1918 on 10.10.10.85. I try to access 81.209.168.100 on port 53 from v516 machine 10.100.198.1 and the only result I see is this ping www.google.de source fasstethernet 0 (where fe0 is 10.100.198.1) tcpdump -i vlan516 host 10.100.198.1 00:06:03.180204 IP 10.100.198.1.52928 > 81.209.168.100.domain: 17+ A? www.google.de. (31) BTW. If I try to ping 81.209.168.100 from 10.100.198.1 nothing returns at the firewall. First of all I tried without using Shorewall FAQ 2b and the result is exactly as tcpdumped above. As I understodd shorewall does not process the traffix out of vlan3006 to its default gateway and back to shorewall´s vlan3003 interface. vlan3006 and vlan3003 are not passed in any way. I am not sure if this is the solution I am looking for but by now it seems to be what could help. After implementing FAQ2b I didn´t see any changes. The attached dump already contains the FAQ2b implementation without success - public interfaces are still not passed. I figured out a way to solve my problem but its silly and not wanted. I connected the two routing tables to each other by telling table 30 the way to 10.10.10.0/24 and telling table 14 the way to 10.100.198.0/24. But this of course is not the reason why we use tables. At all I must grep the above mentioned way I am looking for. Here is a focussed example. v516:10.100.198.1 should leave the firewall through v3006 and should come back to v3003. v3003 should DNAT to 10.10.10.85 udp,tcp port 53 (what it does for outsiders). Then v200:10.10.10.85 should return its answer by passing vlan3003 where vlan3006 still waits for the outstanding answer and relate it from to the previously generated request of v516:10.100.198.1. I am really not sure if this is the best way but it should be a way which commonly known works well. Of course I am interested in another way or maybe in the answer if FAQ2b would be the best one - if I manage it to work. I would really appreciate any help on this. And sorry again for violating the posting rules. Cheers Mike -----Ursprüngliche Nachricht----- Von: Tom Eastep [mailto:teastep@shorewall.net] Gesendet: Sonntag, 17. Januar 2010 04:21 An: Shorewall Users Betreff: Re: [Shorewall-users] ppp+ port forward from internal to external (FAQ 2) Michael Weickel - iQom Business Services GmbH wrote:> > Is someone out there who can help me with this?Not me... We specifically ask that you NOT send us your configuration files (see http://www.shorewall.net/support.htm). The reason that we do that is: a) You configuration is wrong -- otherwise, you wouldn''t be posting on the list. b) By sending us your configuration files, you are focusing our attention on a wrong solution to SOME problem; your configuration files don''t tell us what that problem is, they only show us your incorrect solution to it. c) We would rather that you send us the output of ''shorewall dump'' and tell us, in detail, what you are trying to accomplish and how it is failing. The ''shorewall dump'' output will give us a clear picture of your environment; that together with a precise problem description (see the above URL), will allow us to help you quickly solve your problem. Thanks, -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 \________________________________________________ ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world''s best and brightest in the field, creating opportunities for Conference attendees to learn about information security''s most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev
Michael Weickel - iQom Business Services GmbH
2010-Jan-20 00:07 UTC
Re: WG: ppp+ port forward from internal to external (FAQ2)
Yes you are right - this is the packet for domain lookup and it shows a from v516 originated packet which arrives at the firewall interface vlan516 as an incoming packet where it is shown in the tcpdump. Regarding your chain_masq you are right as well. This was part of my FAQ2a (I spoke earlier from FAQ2b but I mixed it up and meant FAQ2a) implementation where I put v516 v516 172.20.20.5 into the masq file. But this - as I recognized later - is absolutely needless in my scenario. I didnt recognize early enough that FAQ2a means routing within the same zone where I need it between different zones. You wrote that you are lost to why I would see the packet on the interface. I´m not sure if I get your words right but as I feel this is absolutely correct since the packet is originated by a host in zone v516 which of course arrives at the vlan516 interface as an incoming packet. Anyway - I agree that the routing should be correct as it is outlined by you in the given table. And after another hours of investigating it feels that I come closer to where I want to go to. I have a few questions and maybe you know the answer. My shorewall configuration is exactly the same as yesterday. I added a quite important rule to my table. It is ip rule add from 81.209.168.100 to 10.100.198.0/24 table iqom_test_dns But now - and this confuses me even more - I see the first time an event in shorewall log when I try to ping 81.209.168.100 from 10.100.198.1 Jan 20 00:43:15 ffmfw01 kernel: [180907.384017] Shorewall:all2all:DROP:IN=vlan516 OUTMAC=00:1e:58:df:9b:3e:00:17:94:cb:2a:1b:08:00 SRC=10.100.198.1 DST=91.196.142.228 LEN=100 TOS=0x00 PREC=0x00 TTL=254 ID=54127 PROTO=ICMP TYPE=8 CODE=0 ID=178 SEQ=0 This brings me back to my target where I try to have something like this (This is only a fake log but this should be the solution) Jan 20 00:43:15 ffmfw01 kernel: [180907.384017] Shorewall:all2all:DROP:IN=vlan3003 OUT=vlan3006 SRC=217.199.198.157 DST=91.196.142.228 LEN=100 TOS=0x00 PREC=0x00 TTL=254 ID=54127 PROTO=ICMP TYPE=8 CODE=0 ID=178 SEQ=0 If have still problems to figure out how shorewall treats packets originated and destined from and to interfaces which exist in the main table (physically or logically owned by the firewall itself). I have about 15 Shorewall systems running in my network - some or very simple, some are quite complex. But it doesnt matter where I make my tests I always see one rule which is always true. If I originate traffic in a RFC1918 zone connected to a firewall (which is masqueraded lets say at egress/public interface eth1) and destine it to another public interface on the firewall I do see always the RFC1918 ip-address of the host which has originated the traffic by itself. And I never see the public ip of the egress interface (in my example 1) which is in charge of masquerading outgoing traffic which comes out of my RFC1918 zones. Do you see any chance to establish DNAT,MASQ or whatever shorewall rules so that it wont push the packet directly to the well known and directly connected interface but instead cleanly out of its public interface further to the other public interface where it will have regular DNAT access to the local uone behind that one. And of course the way back should be exactly the same - from local through public further access to the earlier originated public one and back to the host which requested? I am quite lucky that I managed to let my local generated packets arrive on the other public interface but know I need some tricks with the source-ip as well as the incoming interface. I see another way how I can solve the problem (maybe) which would be a solution quite close to FAQ2 but in this case I guess there would be no way around connecting the two local zones which are based in different tables to each other and this of course is what I try to prevent as much as I can. What do you think? Do you see a chance to manage the way the packets should walk? Again thanks a lot for joining my scenario. I already received some words which brought about today´s ideas. Cheers Mike -----Ursprüngliche Nachricht----- Von: Tom Eastep [mailto:teastep@shorewall.net] Gesendet: Montag, 18. Januar 2010 18:30 An: Shorewall Users Betreff: Re: [Shorewall-users] WG: ppp+ port forward from internal to external (FAQ2) Michael Weickel - iQom Business Services GmbH wrote:> I will make an example for DNS. It runs public on 81.209.168.100 andRFC1918> on 10.10.10.85. I try to access 81.209.168.100 on port 53 from v516machine> 10.100.198.1 and the only result I see is this > > ping www.google.de source fasstethernet 0 (where fe0 is 10.100.198.1) > > tcpdump -i vlan516 host 10.100.198.1 > 00:06:03.180204 IP 10.100.198.1.52928 > 81.209.168.100.domain: 17+ A? > www.google.de. (31) >Okay -- I''m assuming that this is an incoming DNS packet on vlan516 addressed to 81.209.168.100? Because if were an outgoing packet, it would have been SNATed to 172.20.20.5. Chain vlan516_masq (1 references) pkts bytes target prot opt in out source destination 0 0 SNAT all -- * * 172.20.20.0/24 0.0.0.0/0 policy match dir out pol none to:172.20.20.5 0 0 SNAT all -- * * 10.100.198.0/24 0.0.0.0/0 policy match dir out pol none to:172.20.20.5 So I''m already lost as to why you would see this packet on this interface. There don''t seem to be any DNAT rules for traffic arriving on vlan516 so the packet remains unmodified. It hits this routing rule: 32722: from all iif vlan516 lookup iqom_test_dns That routing table contains: 10.100.198.0/24 via 172.20.20.2 dev vlan516 default via 217.199.198.153 dev vlan3006 So it is shipped off to 217.199.198.153 through vlan3006 where it is masqueraded.> First of all I tried without using Shorewall FAQ 2b and the result is > exactly as tcpdumped above.I saw no sign of FAQ 2b''s solution in that example. I must be missing something, but then your routing configuration is so complex that it would take a week to understand fully (and I''m not going to spend a week on this...). -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 \________________________________________________ ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world''s best and brightest in the field, creating opportunities for Conference attendees to learn about information security''s most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev
Tom Eastep
2010-Jan-20 02:01 UTC
Re: WG: ppp+ port forward from internal to external (FAQ2)
Michael Weickel - iQom Business Services GmbH wrote:> I have a few questions and maybe you know the answer. My shorewall > configuration is exactly the same as yesterday. > > I added a quite important rule to my table. It is > > ip rule add from 81.209.168.100 to 10.100.198.0/24 table iqom_test_dnsThat isn''t helpful unless I know what priority the rule has.> > But now - and this confuses me even more - I see the first time an event in > shorewall log when I try to ping 81.209.168.100 from 10.100.198.1 > > Jan 20 00:43:15 ffmfw01 kernel: [180907.384017] > Shorewall:all2all:DROP:IN=vlan516 OUT> MAC=00:1e:58:df:9b:3e:00:17:94:cb:2a:1b:08:00 SRC=10.100.198.1 > DST=91.196.142.228 LEN=100 TOS=0x00 PREC=0x00 TTL=254 ID=54127 PROTO=ICMP > TYPE=8 CODE=0 ID=178 SEQ=0 > > This brings me back to my target where I try to have something like this > (This is only a fake log but this should be the solution) > > Jan 20 00:43:15 ffmfw01 kernel: [180907.384017] > Shorewall:all2all:DROP:IN=vlan3003 OUT=vlan3006 SRC=217.199.198.157 > DST=91.196.142.228 LEN=100 TOS=0x00 PREC=0x00 TTL=254 ID=54127 PROTO=ICMP > TYPE=8 CODE=0 ID=178 SEQ=0 > > If have still problems to figure out how shorewall treats packets originated > and destined from and to interfaces which exist in the main table > (physically or logically owned by the firewall itself).Shorewall neither knows nor cares how packets are routed. It is your maze of routing tables and rules that determine how packets are routed.> > If I originate traffic in a RFC1918 zone connected to a firewall (which is > masqueraded lets say at egress/public interface eth1) and destine it to > another public interface on the firewall I do see always the RFC1918 > ip-address of the host which has originated the traffic by itself. And I > never see the public ip of the egress interface (in my example 1) which is > in charge of masquerading outgoing traffic which comes out of my RFC1918 > zones.Rewriting the SOURCE IP address is the *last* thing that happens before the packet is queued for delivery. There is no opportunity to log a message after that.> > Do you see any chance to establish DNAT,MASQ or whatever shorewall rules so > that it wont push the packet directly to the well known and directly > connected interface but instead cleanly out of its public interface further > to the other public interface where it will have regular DNAT access to the > local uone behind that one. And of course the way back should be exactly the > same - from local through public further access to the earlier originated > public one and back to the host which requested?I have no idea what you are asking. But again, Shorewall has *NO* control over which interface a packet is routed out of.> > I am quite lucky that I managed to let my local generated packets arrive on > the other public interface but know I need some tricks with the source-ip as > well as the incoming interface. > > I see another way how I can solve the problem (maybe) which would be a > solution quite close to FAQ2 but in this case I guess there would be no way > around connecting the two local zones which are based in different tables to > each other and this of course is what I try to prevent as much as I can. > > What do you think? Do you see a chance to manage the way the packets should > walk?Not with Shorewall... -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 \________________________________________________ ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world''s best and brightest in the field, creating opportunities for Conference attendees to learn about information security''s most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev