I ran a packet capture on a client and the server, and the clients are sending data, but no traffic is showing in the packet capture on the server. Literally none; the box is blank after I stop the packet capture on the OpenVPN server interface.

What I had posted would work? changing every server?

Yes, you can put the servers at the branch offices, like your 2nd diagram, and have 4 clients connecting out from the main office.
But myself, I make my OpenVPN servers listen on a different port to the default (1194) anyway, and it is no problem having 4 of them listening on 4 different port numbers.

Yes, you can use a single site-to-site OpenVPN server with Certificates, have multiple site-to-site OpenVPN clients connecting in and use Client-specific-overrides to tell the server which remote office subnets are reached down which client.
Or you can make 3 separate servers at main office using pre-shared keys, listening on 3 different ports.
If you only have a couple of remote offices then it can be easier to use the pre-shared keys method and have a few servers, rather than bothering to make the certificate authority, certificates,…

Well, the firmware update solved the VPN and aPinger issues.

My long term to do list includes switching this router over the straight pfSense, but all is well for now.

Andy

Thanks heper!
I'll try that.

So i created a new rule at the top my connection status image is attached.

Rules are

LAN
IPv4 * LAN net * * * OpenVPNinterface_VPNV4
IPv4 * LAN net * * * * none

OpenVPNinterface
IPv4 * * * * * * none

OpenVPN
IPv4 * * * * * * none

This results is some very unexpected behavior, i.e. i can only reach a handful of websites and alot of domains become unreachable. My IP is identified as ISP IP and not VPN.

**Update: I got the traffic to route through VPN somewhat. So by adding
redirect-gateway def1, i get the correct Remote IP but i have the same problems mentioned earlier: i can ONLY reach a handful of websites

**Update 2: Ok now it WORKS!! and i am even able to selectively route traffic for specific domain/IPs that i define. I have no idea why it works now, all i know is i m backing this shiz up. Is there a easy way to backup the whole image of the OS and not just configuration?

If someone is pulling their hair with vpn setup on this great software my recommendation is to make changes 1 at a time then reboot and test.

**Update 3: The routing problems were caused by HAVP antivirus, specifically Transparent proxy.


Thanks for the link Mirimir, unfortunately I think we have different ideas of what is "easy-to-follow", besides your page discuss a very different setup, installing pfsense in VM's and what-not.

I already have a dedicated pfsense router that I wish to use. I futher wish to route traffic to one of 3 VPN servers based on protocol/target name/IP address.

My pfsense is set up in what I believe is the standard way for dual wan.  Normally I'd go to the Lan tab and create a new rule, I can make selections for which conditions I'd want to use the VPN, but I can't see where I then pick the VPN link?  I would assume I should pick "Gateway" but when I do that I don't see VPN as a gateway???

The route statements need to be there, so in theory it shouldn't matter whether they're added to the advanced box or generated by the GUI using the new "172.20.10.0/24,172.16.1.0/24" syntax of 2.1.  All the commands get entered into the same config.

So, if using "172.20.10.0/24,172.16.1.0/24" on the remote networks line works while adding routes to the advanced box doesn't… I'm wondering if that's a bug.

For the DEVS Does v2.1 and above now prefer multiple subnets be entered on the "IPv4 Remote Network/s" and "IPv4 Local Network/s" line vs. the advanced config box or are we looking at a possible bug?  Please confirm.

@Marvosa: thanks for your suggestions and observations.

In response to your suggestions:

I already have in place any to any rules in all relevant interfaces in my testbed

I'm not using windows at all, and yes, I have permissive host firewall rules in both desktops at each LAN

I've tried rebooting several times (although not quite after each change/attempt)

It is.

The weirdest thing to me is the fact that when I ping a Client-side LANs desktop from a Server-side LAN desktop and capture traffic at the virtual interface from the PFSense that runs as OpenVPN server (opvpns1) I do see the packets passing through, but I don't see them coming to opvpnc1 (virtual interface from the PFSense that runs as OpenVPN client). It seems as those packets 'get lost' at the OpenVPN tunnel.

And as I mentioned in previous posts, I don't spot any issues either with the traffic routes or with filtered out packets at the firewall log.

Thanks once again though

Thank your !
After I added 192.168.101.0/24 to remote networks in branch office,  all working fine!

102 addres - it was my error while i write this message.

For a working solution, have a look at reply #3 from phil.davis on this thread:

http://forum.pfsense.org/index.php/topic,70066.0.html

Interfaces > (assign), assign the VPN and then enable it with an IP type of "none", then go back and edit/save the VPN to make sure it's started back up OK.

After that you should see a gateway for the VPN in System > Routing, and you can use that gateway in firewall rules to make traffic exit that path.

Depending on the other side you might also need to setup manual outbound NAT rules to do NAT as the traffic leaves the VPN

The most likely cause in this scenario is that your per-interface rules are not being matched as you expect.

If the VPNs are assigned with an IP type of "none" as they should be, make sure you are not using the macros for things like "VPN_1 subnet" and similar. With an IP type of "none" those are really blank/null. If you specify the actual subnets there, the traffic can be matched.

Well… (feeling kinda stupid) :P

I got as far as step 2 and it started working like expected. I haven't had to reboot PFSense devices in ages and didn't occur to me. In my defense, they were also in production use so was not convenient at the time.

Problem solved IPSec had something left over after disabling tunnels that a reboot resolved.

Thanks Marvosa...

@marvosa:

Need to clarify some info:

Your diagram shows "OpenVPN Tunnel Network: 10.0.10.0/24" and "Subnet to pfSense3: 10.0.10.8/30".  Please clarify what you meant because those networks overlap.

When you say "I have a remote site connected with OpenVPN Peer to Peer (SSL/TLS) working" you never specified what was connected. I can only assume from your diagram that you meant PFsense 1 and PFsense 3 are connected and that each side can communicate with the other side's LAN, but please verify my assumption is correct.

On PFsense 2, is there a typo or is 172.16.10.1/26 really a WAN interface? Why isn't it a LAN interface?  I would imagine 172.16.20.0/26 cannot communicate with 172.16.10.0/26 because there is no return route back to 172.16.20.0/26 on PFsense 2.  Although, I'm not even sure that's possible because it's a WAN interface and being NAT'd… someone else chime in if they know for sure

you need a return route to 172.16.20.0/26 on the cisco.

Remember

Post your server1.conf from PFsense 1 and client1.conf from PFsense 3.

pfSense1 Site2Site (PKI)

dev ovpns2 dev-type tun tun-ipv6 dev-node /dev/tun2 writepid /var/run/openvpn_server2.pid #user nobody #group nobody script-security 3 daemon keepalive 10 60 ping-timer-rem persist-tun persist-key proto udp cipher AES-256-CBC up /usr/local/sbin/ovpn-linkup down /usr/local/sbin/ovpn-linkdown local TRIMMED-PUBLIC-IP tls-server server 10.0.10.0 255.255.255.0 client-config-dir /var/etc/openvpn-csc ifconfig 10.0.10.1 10.0.10.2 tls-verify /var/etc/openvpn/server2.tls-verify.php lport 1195 management /var/etc/openvpn/server2.sock unix ca /var/etc/openvpn/server2.ca cert /var/etc/openvpn/server2.cert key /var/etc/openvpn/server2.key dh /etc/dh-parameters.1024 tls-auth /var/etc/openvpn/server2.tls-auth 0 route 172.16.20.0 255.255.255.192 route 172.16.20.64 255.255.255.192 route 192.168.0.0 255.255.255.0 push "route 172.16.0.0 255.255.248.0" push "route 172.16.10.0 255.255.255.192" push "route 10.2.6.0 255.255.255.0" push "route 10.2.31.0 255.255.255.0" push "route 10.31.10.0 255.255.255.0" push "route 10.31.112.0 255.255.255.0" push "route 10.31.253.0 255.255.255.0" push "route 10.32.253.0 255.255.255.0" push "route 10.252.130.0 255.255.255.0" push "route 10.252.144.0 255.255.255.0" push "route 10.252.252.0 255.255.255.0" push "route 10.253.1.192 255.255.255.255" push "route 10.253.252.0 255.255.255.0"

pfSense3 (Client)

dev ovpnc1 dev-type tun dev-node /dev/tun1 writepid /var/run/openvpn_client1.pid #user nobody #group nobody script-security 3 daemon keepalive 10 60 ping-timer-rem persist-tun persist-key proto udp cipher AES-256-CBC up /usr/local/sbin/ovpn-linkup down /usr/local/sbin/ovpn-linkdown local TRIMMED-PUBLIC-IP tls-client client lport 0 management /var/etc/openvpn/client1.sock unix remote TRIMMED-REMOTE-IP 1195 ifconfig 10.0.10.2 10.0.10.1 ca /var/etc/openvpn/client1.ca cert /var/etc/openvpn/client1.cert key /var/etc/openvpn/client1.key tls-auth /var/etc/openvpn/client1.tls-auth 1

Also here is the CSO (-csc) file for that client

ifconfig-push 10.0.10.10 10.0.10.9 iroute 172.16.20.0 255.255.255.192

USING Site2Site

12:00:41.556303 IP 192.168.0.47.38007 > 10.31.10.89.33438: UDP, length 24 12:00:41.628250 IP 192.168.0.47.38007 > 10.31.10.89.33439: UDP, length 24 12:00:41.699052 IP 192.168.0.47.38007 > 10.31.10.89.33440: UDP, length 24 12:00:41.770609 IP 192.168.0.47.38007 > 10.31.10.89.33441: UDP, length 24 12:01:55.579807 IP 192.168.0.47.38022 > 10.31.10.89.33441: UDP, length 24 12:02:00.580990 IP 192.168.0.47.38022 > 10.31.10.89.33442: UDP, length 24 12:02:05.581638 IP 192.168.0.47.38022 > 10.31.10.89.33443: UDP, length 24 12:02:10.582314 IP 192.168.0.47.38022 > 10.31.10.89.33444: UDP, length 24

USING RoadWarrior

11:35:41.019829 IP 10.0.8.202.37905 > 10.31.10.89.33435: UDP, length 24 11:35:41.182282 IP 10.0.8.202.37905 > 10.31.10.89.33436: UDP, length 24 11:35:41.253157 IP 10.0.8.202.37905 > 10.31.10.89.33437: UDP, length 24 11:35:41.324107 IP 10.0.8.202.37905 > 10.31.10.89.33438: UDP, length 24 11:37:07.139149 IP 10.31.253.2.46027 > 10.31.10.89.33438: UDP, length 24 11:37:07.281083 IP 10.31.253.2.15414 > 10.31.10.89.33439: UDP, length 24 11:37:07.351882 IP 10.31.253.2.3381 > 10.31.10.89.33440: UDP, length 24 11:37:07.422730 IP 10.31.253.2.23474 > 10.31.10.89.33441: UDP, length 24