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 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). 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:[email protected]] 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 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 _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
