Re: [Shorewall-users] WG: ppp+ port forward from internal to external (FAQ2)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

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:te...@sh...] 
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 \________________________________________________