Yes, that is correct no drops/rejects from either fw.

And, yes, I was assuming that the home fw was the problem... (which
would be the left fw in my ascii art, but lets not quibble ;-) 

config files, route table and pings from office fw below.

Thanks for all this help, Tom.  
Rick


So here is the office fw openvpn.conf:


# Use a dynamic tun device.
dev tun
# For compatability with 2.x openvpn clients/servers
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
port 50001
disable-occ
local 137.x.y.z
ifconfig 10.1.10.2 10.1.10.1
route 192.168.1.0 255.255.255.0
# Our pre-shared static key
secret static.key

firewall: -root-
# ip route
10.1.10.1 dev tun0  proto kernel  scope link  src 10.1.10.2 
192.168.1.0/24 via 10.1.10.1 dev tun0 
192.168.10.0/24 dev eth1  proto kernel  scope link  src 192.168.10.254 
137.x.y.0/24 dev eth0  proto kernel  scope link  src 137.x.y.z 
137.x.y.0/24 dev ipsec0  proto kernel  scope link  src 137.x.y.z 
default via 137.x.y.55 dev eth0 


firewall: -root-
# ping 10.1.10.1
PING 10.1.10.1 (10.1.10.1): 56 data bytes
64 bytes from 10.1.10.1: icmp_seq=0 ttl=64 time=112.2 ms
64 bytes from 10.1.10.1: icmp_seq=1 ttl=64 time=207.4 ms
64 bytes from 10.1.10.1: icmp_seq=2 ttl=64 time=182.6 ms
64 bytes from 10.1.10.1: icmp_seq=3 ttl=64 time=93.9 ms
64 bytes from 10.1.10.1: icmp_seq=4 ttl=64 time=152.0 ms

firewall: -root-
# ping 192.168.1.2
PING 192.168.1.2 (192.168.1.2): 56 data bytes
64 bytes from 192.168.1.2: icmp_seq=0 ttl=127 time=103.9 ms
64 bytes from 192.168.1.2: icmp_seq=1 ttl=127 time=102.1 ms
64 bytes from 192.168.1.2: icmp_seq=2 ttl=127 time=114.3 ms
64 bytes from 192.168.1.2: icmp_seq=3 ttl=127 time=167.4 ms


-----Original Message-----
From: Tom Eastep [mailto:[EMAIL PROTECTED] 
Sent: Sunday, January 23, 2005 1:26 PM
To: Tibbs, Richard
Cc: [email protected]
Subject: Re: [leaf-user] please help: two openvpn tunnels.

Tibbs, Richard wrote:
> I see no reject or drop messages in Shorewall.log.

On either firewall/router, right.

>  BTW, thanks for your clarification on transitivity.... I assume that
> applies also to policy entries.

Yes.

> 
> Is it possible that Shorewall or the routing process could be silently
> dropping some packets?
> 

I suspect that this is a routing problem, which will silently send
packets off into the great void. It is probably on the return path since
most people fiddle for hours configuring/reconfiguring the traffic path
in the forward direction totally forgetting that for a connection to
work, routing in the opposite direction must also be correct.

> The various Shorewall files are

So you believe that the right-hand firewall/router and network
configuration is irrelevant and that the problem couldn't possibly be
there, right? I assume that you believe that because you have only
included the left-hand configuration files.

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



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
------------------------------------------------------------------------
leaf-user mailing list: [email protected]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Reply via email to