Shorewall users - Dec 2007 - OpenVPN with multi-provider and traffic shaping sending traffic strangely...

Hello,

So, I''ve gotten OpenVPN and Shorewall working in most places... just
not
where it really matters (typical :-)

It seems straightforward in many ways... but, my first guess would be that
there''s a problem with traffic shaping tables and what the chains end
up
wanting to do with packets intended for the vpn (tun0)

The configuration is that there is a client on the firewall / router /
shaper.  The routes all look correct when doing an ip route ls.  But, no
pings work...

Wireshark confirms... when I try to ping 10.8.0.1 from the firewall its
trying to send packets out eth0

In my case, tun0 is not a device to be shaped... but I do have some strict
rules WRT where traffic should go.  However, the simple test of pinging
stuff on the lan (also not shaped) seem fine...  looks like the same kinda
routes to me... and, looking through the normal dumps things seem ok...

I''ve enclosed the dump.. maybe there''s something truly
boneheaded in here...
wouldn''t be the first time.

-glenn

-- 
Glenn H. Tarbox, PhD



-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

A thought on this...there is something different on this machine... its the
only place I have HIGH_ROUTE_MARKS=Yes...

I wonder....

On 12/13/07, Glenn Tarbox, PhD <glenn@tarbox.org>
wrote:
>
> Hello,
>
> So, I''ve gotten OpenVPN and Shorewall working in most places...
just not
> where it really matters (typical :-)
>
> It seems straightforward in many ways... but, my first guess would be that
> there''s a problem with traffic shaping tables and what the chains
end up
> wanting to do with packets intended for the vpn (tun0)
>
> The configuration is that there is a client on the firewall / router /
> shaper.  The routes all look correct when doing an ip route ls.  But, no
> pings work...
>
> Wireshark confirms... when I try to ping 10.8.0.1 from the firewall its
> trying to send packets out eth0
>
> In my case, tun0 is not a device to be shaped... but I do have some strict
> rules WRT where traffic should go.  However, the simple test of pinging
> stuff on the lan (also not shaped) seem fine...  looks like the same kinda
> routes to me... and, looking through the normal dumps things seem ok...
>
> I''ve enclosed the dump.. maybe there''s something truly
boneheaded in
> here... wouldn''t be the first time.
>
> -glenn
>
> --
> Glenn H. Tarbox, PhD
>
>
>

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

On Thu, 2007-12-13 at 15:52 -0800, Glenn Tarbox, PhD wrote:
> 
> I''ve enclosed the dump.. maybe there''s something truly
boneheaded in
> here... wouldn''t be the first time.
> 
You are marking all traffic in both tcout and tcpre. Here''s tcout:

Chain tcout (1 references)
 pkts bytes target     prot opt in     out     source               destination
49003   19M MARK       0    --  *      *       0.0.0.0/0            0.0.0.0/0   
MARK set 0x100
    4   435 MARK       0    --  *      *       0.0.0.0/0           
192.168.0.0/24      MARK set 0x200

So when you ping 10.8.0.1, it will be marked with 0x100.

Here are your route rules:

Routing Rules

0:	from all lookup local 
10256:	from all fwmark 0x100 lookup comcast 
10512:	from all fwmark 0x200 lookup qwest 
20000:	from 24.19.22.67 lookup comcast 
20256:	from 192.168.0.10 lookup qwest 
32766:	from all lookup main 
32767:	from all lookup default 

Clearly a ping to 10.8.0.1 is going to be routed via the
''comcast''
table:

Table comcast:

24.19.16.1 dev eth0  scope link  src 24.19.22.67 
192.168.1.128/25 dev eth1  proto kernel  scope link  src 192.168.1.129 
24.19.16.0/21 dev eth0  proto kernel  scope link  src 24.19.22.67 
169.254.0.0/16 dev eth1  scope link  metric 1000 
default via 24.19.16.1 dev eth0 

The only route matching 10.8.0.1 is the default route out of eth0. So it
should be no mystery whatsoever why the ping packets are going out
through eth0.

What to do about it?

You _could_ add tun0 to comcast''s COPY list but a better idea to add a
route_rule:

#SOURCE                 DEST                    PROVIDER        PRIORITY
-			10.8.0.0/24		254		1000

Now, traffic to 10.8.0.0/24 will be routed using the main table:

10.8.0.17 dev tun0  proto kernel  scope link  src 10.8.0.18 
192.168.100.0/29 via 10.8.0.17 dev tun0 
192.168.1.128/25 dev eth1  proto kernel  scope link  src 192.168.1.129 
10.8.0.0/24 via 10.8.0.17 dev tun0 
...

and the traffic will be correctly routed via 10.8.0.17 out of tun0.

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key



-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

Glenn Tarbox, PhD wrote:
> Hello,
> 
> So, I''ve gotten OpenVPN and Shorewall working in most places...
just not
> where it really matters (typical :-)
> 
> It seems straightforward in many ways... but, my first guess would be that
> there''s a problem with traffic shaping tables and what the chains
end up
> wanting to do with packets intended for the vpn (tun0)
> 
> The configuration is that there is a client on the firewall / router /
> shaper.  The routes all look correct when doing an ip route ls.  But, no
> pings work...
> 
> Wireshark confirms... when I try to ping 10.8.0.1 from the firewall its
> trying to send packets out eth0
That is a routing issue, shows up when the firewall is acting as a
client, with multi-hop gateways defined.
> 
> In my case, tun0 is not a device to be shaped... but I do have some strict
> rules WRT where traffic should go.  However, the simple test of pinging
> stuff on the lan (also not shaped) seem fine...  looks like the same kinda
> routes to me... and, looking through the normal dumps things seem ok...
> 
Have you looked at:

http://www.shorewall.net/MultiISP.html#route_rules

I think all you may need is an entry like this:
-	10.8.0.0/24	main	1000


Jerry

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

On 12/13/07, Tom Eastep <teastep@shorewall.net>
wrote:
>
>
>
> What to do about it?
>
> You _could_ add tun0 to comcast''s COPY list but a better idea to
add a
> route_rule:
>
> #SOURCE                 DEST                    PROVIDER        PRIORITY
> -                       10.8.0.0/24             254             1000
>
> Now, traffic to 10.8.0.0/24 will be routed using the main table:

yup, that fixed it. Thanks.

When I grow up I wanna be smart too :-)

-glenn

-Tom
> --
>
-- 
Glenn H. Tarbox, PhD


-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace