Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have the following VPN configuration:

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

OS: FreeBSD 6.2               OS: Gentoo 2.6.32             OS: Gentoo
Keyname: client3              Keyname: server               Keyname: client1
eth0:              eth0: 203.x.x.x               eth0:
tun0:          tun0:           tun0:
P-t-P:         P-t-P:          P-t-P:

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:





The server config has these routes configured:

push "route"
push "route"

Kino's routing table looks like this:   UG        0 0          0 tun0   UG        0 0          0 tun0   UG        0 0          0 tun0 UH        0 0          0 tun0

Outpost's like this:

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

And Guchuko's like this:   UG        0 0          0 tun0   UG        0 0          0 tun0 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
PING ( 56 data bytes
64 bytes from icmp_seq=0 ttl=63 time=462.641 ms
64 bytes from 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
PING ( 56(84) bytes of data.
--- ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2000ms

Guchuko's tcpdump of tun0 shows:

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

Outpost's tcpdump on tun0 shows:

18:44:00.333341 IP > ICMP echo request, id 63009, seq 3, length 64
18:44:01.334073 IP > ICMP echo request, id 63009, seq 4, length 64
18:44:02.331849 IP > 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 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 and, but 192.168.99 and 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

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


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.