Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
add comment

2 Answers

up vote 5 down vote accepted
+200

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

share|improve this answer
    
Thanks, galets, I'm working on adding the appropriate routes for return traffic. But shouldn't traffic still make its way off the interface onto the VPN server's LAN? as I said above, I can capture the packets from the client LAN on the server's LAN interface but not on the server LAN itself. It's like they're being dropped, but there is a firewall rule allowing any <> any on the LAN interface. –  nedm Oct 14 '09 at 21:19
    
OK, seems to have been sorted out. The routing info you provided is correct and needed to be addressed -- there was another wrinkle that I'll edit the question to add. Thanks for your help. –  nedm Oct 15 '09 at 1:25
add comment

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

share|improve this answer
    
I realize the above link is for an IPsec VPN configuration with pfsense, but openvpn should be similar. –  EEAA Oct 8 '09 at 3:10
    
I haven't tried this on the LAN interfaces -- tried adding a lot of different static routes, but note rules. Could be promising. I'll play with adding LAN-to-LAN rules tomorrow AM. Thanks! –  nedm Oct 8 '09 at 4:02
    
I've tried adding allow rules for any to any on the LAN interfaces of both pfSense systems, and still no luck. I'm configuring the server sytem from the client site, so again, it works for that address, but I can't reach anything else on the server site... maddening. Any other suggestions? –  nedm Oct 8 '09 at 16:52
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.