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:[email protected]] 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 \________________________________________________
status.txt.tar.bz2
Description: Binary data
------------------------------------------------------------------------------ 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
