Pfsense as client will route itself but not others on network

[digininja]

I've got pfsense setup as my default gateway and all traffic routing through it fine. I've got a server setup on the net running as an openvpn server which I can connect to with a normal openvpn client running on any machine.

I've setup pfsense to be a client using pki and when the vpn is enabled the pfsense shell can access through the vpn without any problems however clients on the network connecting through that machine can't see the vpn.

I've only just set this up and haven't added any firewall rules or any special configs yet so I doubt that it is that.

Running a packet trace I can see icmp packets coming into vr2 my lan interface and being passed to tun0 the vpn tunnel but then they disappear, they don't appear the other end of the tunnel.

What could be wrong?

[eureka]

Hi!
To me it sounds like you are not pushing your routes from your remote site to your client when it connects. Look under the "Custom Options" section of your openVPN config. You can add in something like…
push "route 10.10.10.0 255.255.255.0"

This will let the remote openvpn server push the correct routes needed to talk over the VPN to your client. I believe you must also have the "pull" option specified in your custom options for your "client". Using the openvpn gui client my config lists "pull ; Pull route data/DNS from server."

Let me know if this fixes it for you!
-E

@digininja:

I've got pfsense setup as my default gateway and all traffic routing through it fine. I've got a server setup on the net running as an openvpn server which I can connect to with a normal openvpn client running on any machine.

I've setup pfsense to be a client using pki and when the vpn is enabled the pfsense shell can access through the vpn without any problems however clients on the network connecting through that machine can't see the vpn.

I've only just set this up and haven't added any firewall rules or any special configs yet so I doubt that it is that.

Running a packet trace I can see icmp packets coming into vr2 my lan interface and being passed to tun0 the vpn tunnel but then they disappear, they don't appear the other end of the tunnel.

What could be wrong?

[digininja]

That didn't solve it. I already have the push on the server side and adding the pull didn't alter anything on the client side. Routing is sort of working, the pfSense box has the route to the server side and from it I can access all the server network it just isn't routing traffic from my client side lan through the tunnel. Or maybe it is and something else is messing the traffic up. From the client side I can ping 10.8.0.18 which is the IP address of the client side of the tunnel

netstat -r
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            <ext ip="">UGS         0  1476086    vr0
10.8.0.1/32        10.8.0.17          UGS         0      139   tun0
10.8.0.17          10.8.0.18          UH          2        0   tun0</ext> 

Here client.domain.int is on the client lan, 10.8.0.18 is the IP address of the client side of the tunnel and 10.8.0.1 is the server side of the tunnel. Data is getting to tun0 but not getting through, running tcpdump on the server side shows no icmp traffic.

Pinging 10.8.0.18

  [root@firewall.krynn.int]/root(21): tcpdump -i vr2 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vr2, link-type EN10MB (Ethernet), capture size 96 bytes
09:42:36.212795 IP client.domain.int > 10.8.0.18: ICMP echo request, id 20241, seq 1, length 64
09:42:36.213009 IP 10.8.0.18 > client.domain.int: ICMP echo reply, id 20241, seq 1, length 64
09:42:37.212894 IP client.domain.int > 10.8.0.18: ICMP echo request, id 20241, seq 2, length 64
09:42:37.213004 IP 10.8.0.18 > client.domain.int: ICMP echo reply, id 20241, seq 2, length 64
09:42:38.212720 IP client.domain.int > 10.8.0.18: ICMP echo request, id 20241, seq 3, length 64
09:42:38.212818 IP 10.8.0.18 > client.domain.int: ICMP echo reply, id 20241, seq 3, length 64
09:42:39.212563 IP client.domain.int > 10.8.0.18: ICMP echo request, id 20241, seq 4, length 64
09:42:39.212665 IP 10.8.0.18 > client.domain.int: ICMP echo reply, id 20241, seq 4, length 64

Pinging 10.8.0.1

09:42:42.043992 IP client.domain.int > 10.8.0.1: ICMP echo request, id 20497, seq 1, length 64
09:42:43.042979 IP client.domain.int > 10.8.0.1: ICMP echo request, id 20497, seq 2, length 64
09:42:44.049886 IP client.domain.int > 10.8.0.1: ICMP echo request, id 20497, seq 3, length 64
09:42:45.057673 IP client.domain.int > 10.8.0.1: ICMP echo request, id 20497, seq 4, length 64
09:42:46.065990 IP client.domain.int > 10.8.0.1: ICMP echo request, id 20497, seq 5, length 64
^C
13 packets captured
124 packets received by filter
0 packets dropped by kernel
[1.2.3-RELEASE]                                                                                                                                                                               [root@firewall.krynn.int]/root(22): tcpdump -i tun0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type NULL (BSD loopback), capture size 96 bytes
09:42:56.489819 IP client.domain.int > 10.8.0.1: ICMP echo request, id 20753, seq 1, length 64
09:42:57.495748 IP client.domain.int > 10.8.0.1: ICMP echo request, id 20753, seq 2, length 64
09:42:58.503571 IP client.domain.int > 10.8.0.1: ICMP echo request, id 20753, seq 3, length 64

It has to be something simple and easy, it if were this hard to setup client VPNs in pfSense then I'm sure there would have been a lot more noise about it before.

[GruensFroeschli]

For a standard site-to-site connection i would not use a PKI.

If you still insist here is a very good sticky explaining step by step how to get site-to-site connections with a PKI running:
http://forum.pfsense.org/index.php/topic,12888.0.html

[digininja]

This part is site to site but I'm also going to be connecting in to that server from a laptop while travelling so unless I can do shared key and PKI then I'll have to stick to PKI.

I'll have a read through the guide and see what it suggests.

[GruensFroeschli]

Well in this case i would set up 2 servers.
One with a PKI for your roadwarrior
and one PSK for your site-to-site setup.

[digininja]

I can look at doing this.

I can probably get this from google but seeing as you seem to know, why is PKI bad for site-to-site, or why is PSK better?

[GruensFroeschli]

It's not "bad" per se, but just more complicated.
PSK site-to-site is straight forward:
Put key on both sides, define server/client and subnet, set routes which come up on link initiation, done

With a PKI you need to:
Set up a CA, make sure to have client specific configs in place to put routes dependant on with which IP the client connects, configure the relevant route pushes. Also you dont want to push certain routes to certain clients to avoid creating a routing loop.

It just adds another layer of complexity.

[digininja]

ok, PSK sounds much easier I'll look at setting that up. There seem to be plenty of tutorials on doing that .

[digininja]

Fixed it, turns out then encryption had nothing to do with it, that was setup fine all the time, I needed a little extra config on the server side.

To allow clients on the lan behind the pfsense client firewall (192.168.3.0/24) to access machines on server side lan (192.168.4.0/24)  I added this to the server config

client-config-dir ccd
route 192.168.3.0 255.255.255.0

then in a directory called ccd I created a file with the same name as the client cert in use and in it I put

iroute 192.168.3.0 255.255.255.0

And everything stared working.

All this is probably obvious when you understand the inner workings properly but it took me a little while to understand so hopefully this will help anyone else in my position.