TTL Exceeded, multi-network VPN

xibalba

Hello everyone
I have Networks A, B, C

Both Network A and B are tied into C via IPSec (C resides at a data center) but not each other.
I would like to ping a host from Network A on Network B but i recieve a TTL exceeded error.

On my router of Network A (192.168.1.1) I set a static route to 192.168.2.0/24 via 192.168.1.1, I also have a static route to 192.168.0.0/24 via 192.168.1.1 where 192.168.0.0/24 would be Network C and 192.168.2.0/24 is Network B.
After setting the static route i try to ping and traceroute 192.168.2.0 and this is what i get
C:\Documents and Settings\Administrator>ping 192.168.2.0

Pinging 192.168.2.0 with 32 bytes of data:

Reply from 192.168.1.1: TTL expired in transit.
Reply from 192.168.1.1: TTL expired in transit.

C:\Documents and Settings\Administrator>tracert -d 192.168.2.1

Tracing route to 192.168.2.1 over a maximum of 30 hops

1 <1 ms <1 ms <1 ms 192.168.1.1
2 <1 ms <1 ms <1 ms 192.168.1.1
3 <1 ms <1 ms <1 ms 192.168.1.1
…...

Here is my routing table

netstat -rn

Routing tables

Internet:
Destination Gateway Flags Refs Use Netif Expire
default 72.132.236.1 UGS 0 885088 xl0
72.132.236/23 link#1 UC 0 0 xl0
72.132.236.1 00:08:e2:30:c4:a9 UHLW 2 3130 xl0 1178
72.132.236.227 127.0.0.1 UGHS 0 0 lo0
127.0.0.1 127.0.0.1 UH 1 18222 lo0
192.168.0 192.168.1.1 UGS 0 105 dc0
192.168.1 link#2 UC 0 0 dc0
192.168.1.1 00:03:6d:18:09:b2 UHLW 3 2 lo0
192.168.1.7 00:0a:cd:11:2d:61 UHLW 1 45037 dc0 1182
192.168.1.37 00:13:d4:51:6d:7c UHLW 1 140924 dc0 719
192.168.1.192 00:13:20:48:25:c5 UHLW 1 1447 dc0 724
192.168.1.199 00:10:4b:95:d4:9b UHLW 1 30576 dc0 772
192.168.2 192.168.1.1 UGS 0 0 dc0

From the machine at the data center (192.168.0.1)
I can ping both 192.168.1.1 and 192.168.2.1

ping -c 1 192.168.1.1; ping -c 1 192.168.2.1

PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=34.155 ms

--- 192.168.1.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 34.155/34.155/34.155/0.000 ms

PING 192.168.2.1 (192.168.2.1): 56 data bytes
64 bytes from 192.168.2.1: icmp_seq=0 ttl=64 time=28.758 ms

--- 192.168.2.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 28.758/28.758/28.758/0.000 ms

Thanks for any help.

hoba

Static routes won't help you with ipsec. You created a loop (that's why you see always the same hop until it dies).

Let's assume your datacenter(C) is the concentrater for all private networks that will be attached via vpn:

Delete all routes that you introduced for your VPN setup and create tunnels like this:

A to C (make both sides of the tunnel use these networks):
Network at A: LAN subnet of A
Network at C: 192.168.0.0/16

B to C (make both sides of the tunnel use these networks):
Network at A: LAN subnet of B
Network at C: 192.168.0.0/16

This way anything that is not found locally at A or B as directly connected subnet but starts with 192.168.anything will be send to the concentrator. If the concentrator has this subnet or a tunnel to it it will be forwarded. If not it dies at the concentrator. Because of the /16 subnetmask you can attach more subnets to the concentrator when your network grows without needing to reconfigure other locations.

xibalba

So if I'm not mistaken you mean to setup Network C (Concentrator) as such

Network A (my house)

Network B (friends house)

Also on a side note, when posting these images to my webserver at home (192.168.1.7) my router's WAN ip changed and dhclient had re-run and updated the IP. I noticed however that the NAT RDR rules were still using the old IP. Any chance when dhclient updates any rules dependent on the WAN IF IP can be rewritten and updated? Simply clicking edit on one NAT RDR rules, then save/apply fix it.

hoba

This is completely wrong. You don't need any static routes. You need the subnets in the tunneldefinition the way I posted them. IPSEC has nothing to do with static routes or if you want to see it this way: it will "somehow create the routes" the way that you specify the subnets in the tunnel definitions.

I haven't noticed a DHCP client bug yet but I have to admit that I either use static IPs or PPPoE connections everywhere. However PPPoE is dynamic with 24h forced disconnects by the provider with IP-Change. PPPoE works fine this way. Anybody else noticed DHCP client problems with portforwards/firewallrules?