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_dns
That 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 \________________________________________________
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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
