• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

FreeBSD IPsec Tunnel works... but...

groovin

Senior member
my one test workstation cant get to anything besides whats on the LAN and tunnel...

ok heres my set up, test1 and test2 are FreeBSD 5.1 gateways using racoon and isc-dhcp3. fxp1 and em1 are both public IP's. fxp0=192.168.5.1 and em0=192.168.6.1. w2k is a workstation i have setup using DHCP. it pulls 192.168.6.254.

fxp0| test1 |fxp1 <-----IPsec/VPN tunnel----->em1| test2 |em0 ---- w2k

i have the tunnel up and running...

here is what i can ping:

w2k-fxp0 (w2k can ping the internal interface of test1... so, 192.168.6.254 can ping 192.168.5.1)
test1-w2k
w2k-em0 and em1

what i cannot ping:

w2k--fxp1
w2k--any www sites

so in summary, w2k cannot access the public internet. tracert just hangs... tcpdump shows nothing. so the tunnel works, but the w2k machine just cannot communicate with anything outside the tunnel. no firewalls running, and my routing table look ok (to me at least).

my first thoughts are that the routing table is missing something or the IPsec tunnel is interfereing with normal unencryted traffic...

any ideas?? thanks

--btw i love this forum.
 
just did some tcpdumping...

if i ping fxp1 from win2k, the tcpdump traffic shows the private IP of w2k (192.168.6.254) trying to ping it (fxp1). so, it looks like traffic is getting out there, but for some reason the private ip is being placed on the packet which is probaly why nothing wants to reply to a RFC defined private IP.

why is this happening?
 
It sounds like your ipsec policy is routing all traffic through the tunnel.

Double check your ipsec policies to be sure that just "lan" traffic is sent through the tunnel.

The other issue with the win2k-fpx1 ping not going through is because the magical route ipsec creates does not include a path to the default lan gateway of the remote network (in this case 192.168.5.1). This script on test2 should fix that problem:

/usr/local/etc/rc.d/routes.sh

#!/bin/sh

case "$1" in
start)
/sbin/route -q add -net 192.168.5.0/24 192.168.6.1 && echo -n ' routes'
;;
stop)
/sbin/route -q delete -net 192.168.5.0/24 192.168.6.1 && echo -n ' routes'
;;
*)
echo "Usage: `basename $0` {start|stop}" >&2
exit 64
;;
esac

--


Edit: I think I misread the problem. It's still a good idea to use that script, but it won't fix the problem of not being able to ping fxp1 from w2k. You would need to create an additional policy, separate from the one that routes traffic to the private lan side of test2.

~bex0rs

 
got it figured out...

what was happening was NATd wasnt starting up properly for whatever reason. that explains why packets going out of the router kept their private IPs. Its not that the machines on the other end werent getting the packets, its just that they didnt know how to reply to them since the source IP was a RFC defined private subnet.

Thanks for your help though bex!
 
Back
Top