Connected but "network unreachable"

deagle

I have used pfsense for openvpn remote access in the past and it has always worked well. I redid my home network with a L3 switch and vlans and now I'm having trouble with openvpn. I set it up this morning and it connects and configures my tun0 interface as 10.0.8.6. But when trying to access my DG or any other interface on the DG's internal network, it would fail with "network unreachable", accessing interfaces on other subnets also fails (I have static routes in pfsense pointing to the L3 switch interface and that works when connected locally).

I added a rule on the LAN firewall to pass all traffic from 10.0.8.0/24 (vpn network) to any destination and reconnected, then everything worked, I was able to access pfsense and all my vlans by going through a static route to my L3 switch interface. I never needed this rule before but I figured it wouldn't hurt, although I'm not sure if it was the reason the vpn was working correctly.

I went to lunch and the laptop went to sleep breaking the connection, came back and it reconnected and now I can't ping or connect to anything again.

I must be overlooking something simple but I just can't figure it out. I'm using viscosity on osx 10.8 and pfsense is running as a ESXi vm, the lan subnet is 10.1.1.0/24, the other subnets are routed on the L3 switch. I will gladly provide any additional information if someone can make sense of this. Thanks.

heper

the other subnets are routes on the L3 switch

while this might be true….
how would a remote client be able to connect to subnets behind the L3 switch, when the client does not know that it needs to go through the openvpn-server to reach them?

In other words, you openvpn client needs routes for subnetA using L3-switch

see advance configuration:
push "route subnetA 255.255.255.0" ;

then make sure your pfsense also knows where to find subnetA (ie static routes or ospf or ....)

deagle

the static routes are in place in pfSense, for example:

10.1.2.0/24 via 10.1.1.1 (L3 switch interface)
10.1.3.0/24 via 10.1.1.1

And I agree that my OpenVPN client might need to know those, assuming they aren't included in the config file I generated with the export utility.

What I don't understand is why it was working briefly… and why I can't hit anything on the 10.1.1.0/24 network, which is where the pfSense inside interface is (10.1.1.254) and which should be routed automatically.