Selective routing over openVPN

[xopah]

Hi folks!

I have got an issue with selective routing over openVPN.
The tunnel is working fine and is up and stable.
I want to route a /24 IP range over the tunnel out on the net on the openVPN server side.

The route is pushed out from openVPN server.
Traceroute from openvpn client pfsense works.
Traceroute from local client behind pfsense client does not work.
Pfsense version:
2.0-RELEASE (i386)
built on Tue Sep 13 17:28:43 EDT 2011

Packet capture on pfsense client gives:

20:23:45.700473 AF IPv4 (2), length 56: (tos 0x0, ttl 127, id 8520, offset 0, flags [DF], proto TCP (6), length 52)
    computer.client.local.55757 > xzy.com.http: Flags [s], cksum 0xf795 (correct), seq 2840697305, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
20:23:48.706961 AF IPv4 (2), length 56: (tos 0x0, ttl 127, id 8531, offset 0, flags [DF], proto TCP (6), length 52)
    computer.client.local.55757 > xzy.com.http: Flags [s], cksum 0xf795 (correct), seq 2840697305, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
20:23:48.847735 AF IPv4 (2), length 56: (tos 0x0, ttl 127, id 8532, offset 0, flags [DF], proto TCP (6), length 52)
    computer.client.local.55758 > xzy.com.http: Flags [s], cksum 0xd864 (correct), seq 3951720144, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
20:23:51.857434 AF IPv4 (2), length 56: (tos 0x0, ttl 127, id 8534, offset 0, flags [DF], proto TCP (6), length 52)
    computer.client.local.55758 > xzy.com.http: Flags [s], cksum 0xd864 (correct), seq 3951720144, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
20:23:54.707535 AF IPv4 (2), length 52: (tos 0x0, ttl 127, id 8541, offset 0, flags [DF], proto TCP (6), length 48)
    computer.client.local.55757 > xzy.com.http: Flags [s], cksum 0x0b9f (correct), seq 2840697305, win 8192, options [mss 1460,nop,nop,sackOK], length 0
20:23:57.851569 AF IPv4 (2), length 52: (tos 0x0, ttl 127, id 8542, offset 0, flags [DF], proto TCP (6), length 48)
    computer.client.local.55758 > xzy.com.http: Flags [s], cksum 0xec6d (correct), seq 3951720144, win 8192, options [mss 1460,nop,nop,sackOK], length 0
20:24:06.708467 AF IPv4 (2), length 56: (tos 0x0, ttl 127, id 8560, offset 0, flags [DF], proto TCP (6), length 52)
    computer.client.local.55759 > xzy.com.http: Flags [s], cksum 0x25ef (correct), seq 2272562523, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
20:24:09.710254 AF IPv4 (2), length 56: (tos 0x0, ttl 127, id 8562, offset 0, flags [DF], proto TCP (6), length 52)
    computer.client.local.55759 > xzy.com.http: Flags [s], cksum 0x25ef (correct), seq 2272562523, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
20:24:15.706521 AF IPv4 (2), length 52: (tos 0x0, ttl 127, id 8570, offset 0, flags [DF], proto TCP (6), length 48)
    computer.client.local.55759 > xzy.com.http: Flags [s], cksum 0x39f8 (correct), seq 2272562523, win 8192, options [mss 1460,nop,nop,sackOK], length 0
20:24:27.713565 AF IPv4 (2), length 56: (tos 0x0, ttl 127, id 8583, offset 0, flags [DF], proto TCP (6), length 52)
    computer.client.local.55762 > xzy.com.http: Flags [s], cksum 0x57ae (correct), seq 1355911740, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
20:24:30.714143 AF IPv4 (2), length 56: (tos 0x0, ttl 127, id 8585, offset 0, flags [DF], proto TCP (6), length 52)
    computer.client.local.55762 > xzy.com.http: Flags [s], cksum 0x57ae (correct), seq 1355911740, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
20:24:36.708892 AF IPv4 (2), length 52: (tos 0x0, ttl 127, id 8591, offset 0, flags [DF], proto TCP (6), length 48)
    computer.client.local.55762 > xzy.com.http: Flags [s], cksum 0x6bb7 (correct), seq 1355911740, win 8192, options [mss 1460,nop,nop,sackOK], length 0
20:24:48.721856 AF IPv4 (2), length 56: (tos 0x0, ttl 127, id 8606, offset 0, flags [DF], proto TCP (6), length 52)
    computer.client.local.55764 > xzy.com.http: Flags [s], cksum 0x8e39 (correct), seq 669025440, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
20:24:51.718478 AF IPv4 (2), length 56: (tos 0x0, ttl 127, id 8613, offset 0, flags [DF], proto TCP (6), length 52)
    computer.client.local.55764 > xzy.com.http: Flags [s], cksum 0x8e39 (correct), seq 669025440, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
20:24:57.710189 AF IPv4 (2), length 52: (tos 0x0, ttl 127, id 8618, offset 0, flags [DF], proto TCP (6), length 48)
    computer.client.local.55764 > xzy.com.http: Flags [s], cksum 0xa242 (correct), seq 669025440, win 8192, options [mss 1460,nop,nop,sackOK], length 0

What am I doing wrong here?
Is it a firewall rule I have overlooked?
[/s][/s][/s][/s][/s][/s][/s][/s][/s][/s][/s][/s][/s][/s][/s]

[xopah]

Im here to post a small update as my serch for get the problem solved continues, but have not heard anything word from here yet.

Apparently the server pfsense tries to answer my client mashine:

 15:16:52.719307 IP 192.168.10.XX.36926 > XX.XX.XX.XX.33437: UDP, length 32
15:16:52.719366 IP 10.0.46.1 > 192.168.10.XX: ICMP time exceeded in-transit, length 36

It says:

The Time Exceeded Message is an ICMP message which is generated by a gateway to inform the source of a discarded datagram due to the time to live field reaching zero.

IS there a routing loop that Im unaware of?

Pinging…

15:39:00.409877 IP 192.168.XX.XX > XX.XX.XX.XX: ICMP echo request, id 46352, seq 172, length 64
15:39:01.410151 IP 192.168.XX.XX > XX.XX.XX.XX: ICMP echo request, id 46352, seq 173, length 64
15:39:02.467118 IP 192.168.XX.XX > XX.XX.XX.XX: ICMP echo request, id 46352, seq 174, length 64

No answer at all!

• And the same issue with forwarding google.

Updated pfsense to 2.0.1 release
Still same issue.

It seems like the packets goes out from the openVPN server side WAN but does not get any answer.
And the two pfsense routers seems to get different IP's from the DNS server for the same domain name.

So I'm still not able to route the /24 net out on a different WAN through a openVPN tunnel.

any suggestions would be awsome!
Thanks!

[cmb]

You definitely have a routing loop somewhere, not enough details there to tell you where.