Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I have the following VPN configuration:

+------------+                +------------+                +------------+
|  outpost   |----------------|    kino    |----------------|  guchuko   |
+------------+                +------------+                +------------+

OS: FreeBSD 6.2               OS: Gentoo 2.6.32             OS: Gentoo 2.6.33.3
Keyname: client3              Keyname: server               Keyname: client1
eth0: 10.0.1.254              eth0: 203.x.x.x               eth0: 192.168.0.6
tun0: 192.168.150.18          tun0: 192.168.150.1           tun0: 192.168.150.10
P-t-P: 192.166.150.17         P-t-P: 192.168.150.2          P-t-P: 192.168.150.9

Kino is the server and has client-to-client enabled. I am using "fragment 1400" and "mssfix" on all three machines. An mtu-test on both connections is successful. All three machines have ip forwarding enabled, by this on the gentoo boxes:

net.ipv4.conf.all.forwarding = 1

And this on the FreeBSD box:

net.inet.ip.forwarding: 1

In the server's "ccd" directory is the following files:

client1:

iroute 192.168.0.0 255.255.255.0

client3:

iroute 10.0.1.0 255.255.255.0

The server config has these routes configured:

push "route 192.168.0.0 255.255.255.0"
push "route 10.0.1.0 255.255.255.0"
route 192.168.0.0 255.255.255.0
route 10.0.1.0 255.255.255.0

Kino's routing table looks like this:

192.168.150.0   192.168.150.2   255.255.255.0   UG        0 0          0 tun0
10.0.1.0        192.168.150.2   255.255.255.0   UG        0 0          0 tun0
192.168.0.0     192.168.150.2   255.255.255.0   UG        0 0          0 tun0
192.168.150.2   0.0.0.0         255.255.255.255 UH        0 0          0 tun0

Outpost's like this:

192.168.150        192.168.150.17     UGS         0       17   tun0
192.168.0          192.168.150.17     UGS         0        2   tun0
192.168.150.17     192.168.150.18     UH          3        0   tun0

And Guchuko's like this:

192.168.150.0   192.168.150.9   255.255.255.0   UG        0 0          0 tun0
10.0.1.0        192.168.150.9   255.255.255.0   UG        0 0          0 tun0
192.168.150.9   0.0.0.0         255.255.255.255 UH        0 0          0 tun0

Now, the tests.

Pings from Guchuko to Outpost's LAN IP work OK, as does the reverse - pings from Outpost to Guchuko's LAN IP. However...

Pings from Outpost, to a machine on Guchuko's LAN work fine:

 .(( root@outpost )).  (( 06:39 PM ))  :: ~ ::
# ping 192.168.0.3
PING 192.168.0.3 (192.168.0.3): 56 data bytes
64 bytes from 192.168.0.3: icmp_seq=0 ttl=63 time=462.641 ms
64 bytes from 192.168.0.3: icmp_seq=1 ttl=63 time=557.909 ms

But a ping from Guchuko, to a machine on Outpost's LAN does not:

 .(( root@guchuko )).  (( 06:43 PM ))  :: ~ ::
# ping 10.0.1.253
PING 10.0.1.253 (10.0.1.253) 56(84) bytes of data.
--- 10.0.1.253 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2000ms

Guchuko's tcpdump of tun0 shows:

18:46:27.716931 IP 192.168.150.10 > 10.0.1.253: ICMP echo request, id 63009, seq 1, length 64
18:46:28.716715 IP 192.168.150.10 > 10.0.1.253: ICMP echo request, id 63009, seq 2, length 64
18:46:29.716714 IP 192.168.150.10 > 10.0.1.253: ICMP echo request, id 63009, seq 3, length 64

Outpost's tcpdump on tun0 shows:

18:44:00.333341 IP 192.168.150.10 > 10.0.1.253: ICMP echo request, id 63009, seq 3, length 64
18:44:01.334073 IP 192.168.150.10 > 10.0.1.253: ICMP echo request, id 63009, seq 4, length 64
18:44:02.331849 IP 192.168.150.10 > 10.0.1.253: ICMP echo request, id 63009, seq 5, length 64

So Outpost is receiving the ICMP request destined for the machine on it's subnet, but appears not be forwarding it. Outpost has gateway_enable="YES" in its rc.conf which correctly sets net.inet.ip.forwarding to 1 as mentioned earlier. As far as I know, that's all that's required to make a FreeBSD box forward packets between interfaces. Is there something else I could be forgetting ? FWIW, pinging 10.0.1.253 from Kino has the same result - the traffic does not get forwarded.

UPDATE: I've found that I can only ping certain IP's on Guchuko's LAN from Outpost. From Outpost I can ping 192.168.0.3 and 192.168.0.2, but 192.168.99 and 192.168.0.4 are unreachable. The same tcpdump behavior can be seen. I think this means the problem can't be due to ipforwarding or routing, because Outpost can reach SOME hosts on Guchuko's LAN but not others and likewise, Guchuko can reach two hosts on Outpost's LAN, but not others. This baffles me.

share|improve this question

2 Answers 2

Two things I would check:

First, check that there isn't a firewall or something on the un-pingable hosts that eats icmp.

Second, check the routing rules on the machines you can't ping to ensure they have route entries that will get replies back to the VPN gateway (either directly or via a default route that knows how to get to the VPN gateway). Snoop/wireshark the target interface on the unpingable node to ensure you can see the requests coming in and where the replies are going.

share|improve this answer
    
yep, seems like problem on target machines for me too. Traceroute from unpingable machines should also help. –  apagr Feb 28 '13 at 13:21
  1. Did you check the scope of the firewall inside the faulty LAN's?
  2. What tcpdump on physical LAN interface show? Can you run one on tun0 and one on eth0 (or whatever the name of your LAN interface is) and check where the traffic brakes? Maybe it's just a lack of answer on the client machine side (like mentioned before invalid scope setting)
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.