Home / server / Questions / 72391
Accepted
nedm
Asked: 2009-10-08 18:53:52 +0800 CST

pfSense Site-toSite VPN with OpenVPN connects but won't route traffic

  • 772

Using two pfSense routers, I've created a shared-key VPN between 2 sites. Both routers are pfSense 1.2.2. The pfSense box at the client site is the gateway router for that site, but at the server site the pfSense is NOT the gateway for that LAN. The client site connects to the server site OK, and I get the "Initialization Sequence Completed" log message indicating the connection is successful.

From the client site, I can then use any machine on the client LAN to ping the pfSense box at the server site on its LAN address (and even configure it through the web interface, so the VPN is working for this address at least). I can also ping both addresses in the "Interface IP" (client config)/"Address Pool" (server config) IP range, which are the same private subnet and are NOT in either the client or server LAN ranges.

The problem is that I can't access any other IPs on the server site LAN. I don't need to be able to access machines on the client site LAN from the server site, but I do need to be able to get to more than just the server from the client site. Currently, anyone on the client LAN can ping as far as the LAN interface of the server, and anyone on the client LAN can be pinged from the pfSense server itself, but not from the server LAN. I've added an any <> any rule on the LAN interface firewall rules on the server.

If I capture traffic on the server's LAN interface, I see packets passed from the client LAN site, but if I sniff I don't see these packets making it onto the server's LAN. As I said, I've added a rule on the LAN interface to allow any-to-any as below, so what else do I need to do to allow traffic from the tunnel to the LAN and vice versa?

Update : I've added a push route for the server LAN on the client pfSense and vice versa. I've also tried upgrading to the RC of pfSense 1.2.3 and adding an Opt1 interface set to tun0, then adding allow rules between opt1 and the LAN. Still no luck.

Update 2: Needed to set correct routing on the server LAN as described in the accepted answer, but I neglected to mention the server pfSense/OpenVPN unit was running as a guest OS under KVM, and the other half of the problem was that IP forwarding needed to be enabled in the /etc/ufw/before.rules of the host OS. That's what I get for not explaining the setup more thoroughly.

openvpn

2 Answers

  1. Best Answer

    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

    • 8

  2. Did you create firewall rules to allow the traffic to flow where you want it?

    • 2