PfSense – Site to Site OpenVPN

Here's what may be an issue. Imagine you have following network:

address pool: 10.1.1.0/255.255.255.0
router: 10.1.1.1
internal interface on internal vpn server: 10.1.1.2
some external machine that VPNs to network: 10.2.2.2
some internal client machine: 10.1.1.90

When you trying to access SIC from external VPN box, then traffic route goes like this:

• 10.2.2.2
• vpn (internet)
• 10.1.1.2
• 10.1.1.90
• OK

Seems fine, HOWEVER, in order for traffic to flow, the 10.1.1.90 machine should be able to respond and that means that packets from it must be routable to 10.2.2.2 too. Internal client has obviously ip: 10.1.1.90, mask: 255.255.255.0 and router: 10.1.1.90. Therefore, packets would be routed like this:

• 10.1.1.90
• 10.1.1.1 (sine it is router, and 10.2.2.2 is not directly addressable)
• internet
• NOT FOUND

Basically, reply packets will not even reach VPN. What can you do? Obviously, what will work is to add route to internal client to route all packets to 10.2.2.2 not to VPN box instead of router, such as (Windows box):

route add 10.2.2.0 mask 255.255.255.0 10.1.1.2

this will resolve the problem on single-machine level. Reply packets will go:

• 10.1.1.90
• 10.1.1.2 (explicit route)
• vpn (internet)
• 10.2.2.2

To resolve issue on the network level, you must modify router in a same matter to redirect all traffic going to 10.2.2.0 to 10.1.1.2. This way reply packet will go:

• 10.1.1.90
• 10.1.1.1
• 10.1.1.2
• vpn (internet)
• 10.2.2.2

Another solution is: make your VPN box to NAT on 10.1.1.2 interface. This way for internal machines it will look as if all the traffic originates from 10.1.1.2, and replies will go to 10.1.1.2. I would advise to go through routing though, since NAT will require additional resources on VPN box for connection tracker

With SSL/TLS site to site VPNs, you need the route on the server, and the iroute in a client specific override. The description here sounds like you're missing that iroute. Unlike shared key, where the route on the server suffices. In the case of VPNs like this, the route on the server sends that traffic to that particular OpenVPN instance, and its internal routing, via iroutes, must know which client to route that particular network.

Under VPN>OpenVPN, Client Specific Override tab, add a new entry. For the "Common name", put in the CN from the certificate on the client side. In the Advanced box, fill in "iroute 10.34.43.0 255.255.255.0" (sans quotes). Leave the rest at defaults, click Save. Restart the OpenVPN client from Status>Services on the client system, and once it reconnects, it should work if it is indeed the missing iroute.