I can't access that image either, but the way that I did it was to add an advanced option to the rule that passes traffic through the interface - the advanced option specifies the gateway as being the VPN interface dynamic gateway.

Hi together, As i remember, there was an fix-package available for openvpn-tap. Never needed to use tap before on pfSense. The System is a fresh and clean 2.1-installation, even one day ago. Peer is an mikrotik device with RouterOS 6.4, where other windows-clients are able to connect successfully. Thanks in advance for replies.

@Nadar: @Fevan: 1st post and no experience compared to the guys around here but I did use airvpn with my tomato openvpn client with Asus router and never had this issue. This forum/thread is about OpenVPN and pfSense (an open source firewall/router++). How does pfSense come into play with your setup? More specifically, we're discussing terminating the VPN tunnel in the firewall/router, not using a client. Using a client through pfSense is probably completely unproblematic. oh my bad I thought op was having disconnection issues with airvpn and pfsense.  Thought the settings on openvpn on the AirVPN forums may help him. Good news to hear however using a client through pfsense is hopefully all working well,  I plan on going through the same route when I can figure out the basics !

anyone help me?

I use a tun device for my OpenVPN server. Not sure if that changes anything.

Hi, you can use "Client specific override" if you are using RoadWarrior setup with certificates. Just put the CN of the certificate of the user in the "client specific override" and put there the tunner /30 network this user always should get. On pfsense 2.0.3 you have to do that for every user if the users on OpenVPN should always get the same IP-address/subnet. On pfsense 2.1 - if I remember correct - there could be an additional option which allows you to not user /30 tunnels but single addresses. But I did not test that. The tunne network on the OpenVPN server confing for example is /24. This means that there could be max. 64-1 clients connect which always use /30.

Hi pfbits, I found out myself after you pointed me in the right direction. I had a faulty DNS suffinx setting on the VPN adapter. This was due to misconfiguration of OpenVPN (I changed my domain name at one time). So now everything is working as it should. Thank you very much for helping me out.

More detail: I connected to ovpn. I then connected to a vmware vsphere application to use the console of one of the VM's in the office. I compared pinging from the VM to pinging from my home laptop. Format: Internal IP / ping from home Y/N / ping from VM Y/N / description ex: 1 Y/Y - office pfsense means the IP of the machine is 192.168.1.1  (note the "1"), and the Y/Y means I could ping it from both the internal VM and my home laptop. To me, the anomalies are the .10 server attached to the same "server switch" that seems to provide the most reliable results.  I assume this is a client firewall issue on the .10 machine itself. Also the difference between the .60 and .68 - why would one machine on a random switch respond to ping, but the other would not?  Again, do I assume a client firewall issue? Finally, the .22 machine is the internal test machine we've been working with.  Firewall on or off, no difference.  Static route on the machine or not, no difference. It still seems that most of the machines on the "server switch" want to act right, while most of the machines on other 8port workgroup switches in the office want to not work at all.  I would chalk it up to "firewall" on all machines if it wasn't for the fact that I know we have 100% disabled the Windows firewall on the .22 Ip with the same (failed) results. EDIT: I should note, notice that from an internal machine on the LAN, all pings to target machines worked as expected. (The "Y/Y? column has all Y in the 2nd part) EDIT2: for IP's 57-84 I cannot comment on the OS or state of the firewall at this point - I assume some are on, some are off.  I also assume that most (if not all) are Windows 7 workstations. 1 Y/Y - office pfsense 5 Y/Y - office 24port switch directly attached to pfsense 7 Y/Y - wifi access point daisy-chained to an 8port workgroup switch 9 N/Y - wifi access point daisy-chained to an 8port workgroup switch 10 N/Y - physical server (windows) attached to 8port "server switch" 11 Y/Y - physical server (linux) attached to 8port "server switch" 12 Y/Y - physical server (windows) attached to 8port "server switch" 13 Y/Y - physical server (imac running OSX) attached to 8port "server switch" 14 Y/Y - physical server (vmware esxi) attached to 8port "server switch" 15 Y/Y - 2nd physical server (vmware esxi) attached to 8port "server switch" 16 Y/Y - vm guest OS (linux) on vm1 (ip .14) 17 Y/Y - vm guest OS (linux) on vm1 (ip .14) 20 Y/Y - physical NAS server (synology) attached to 8port "server switch" 21 Y/Y - vm guest OS (windows 7) on vm2 (ip .15) 22 N/Y - physical workstation (windows) - my primary internal test machine 30 Y/Y - vm guest os (linux) on vm1 (ip .14) 33 N/Y - vm guest os (linux) on vm1 (ip .14) 35 Y/Y - vm guest os - linux - 2nd NIC of physical vm server - this is the mirror port of the 24 port switch attached to pfsense 37 Y/Y - vm guest os (linux) on vm1 (ip .14) 57 Y/Y - physical workstation attached to some misc 8port workgroup switch, attached to the 24 port switch that is attached directly to pfsense 60 Y/Y - physical workstation attached to some misc 8port workgroup switch, attached to the 24 port switch that is attached directly to pfsense 68 N/Y - physical workstation attached to some misc 8port workgroup switch, attached to the 24 port switch that is attached directly to pfsense 70 N/Y - physical workstation attached to some misc 8port workgroup switch, attached to the 24 port switch that is attached directly to pfsense 79 N/Y - physical workstation attached to some misc 8port workgroup switch, attached to the 24 port switch that is attached directly to pfsense 84 Y/Y - physical workstation attached to some misc 8port workgroup switch, attached to the 24 port switch that is attached directly to pfsense

Hi did you ever get this working? I am trying myself to get this working (open vpn and IP Alias) but no luck so far.

How many nodes does your home network consist of? normally for home users its one computer and router and maybe a few ipads for the kids. Just change the network range on the router. So much easier!

I figured it out! The missing piece was that I had to create a new interface (which I called "BRG") and added the bridge adapter to it. From there, I was able to assign it an IP address (which wasn't necessary except for ping testing), and, most importantly, add firewall rules to that interface. From there, it was a simple matter of adding an allow any to any rule on that interface, and now I can ping over the bridged VPN.

Hi, Has anybody any other recommendations for a vpn provider? Thanks Richard

I had the exacy same problem for quite some time, and it's still not quite clear to me why it doesn't work, but this is what I found: The port forwarding itself work just fine, the problem is when you combine this with policy routing in such a way that you need a policy route to "activate" to route the traffic out through the correct interface. Since the incoming, port-forwarded packets are placed in the state table, and thus when the computer on the inside replies to that packet, the reply is automatically accepted via the state table. Because of this, the policy routing rule is never evaluated, and thus the packet defaults to the default routing table - usually ending up exiting through your WAN, not the VPN tunnel. Since these addresses are normally in a private range, the packet will just die alone in the cold in some router out there on the internet. In pfSense 2.1 they have made some fix to this that auto creates a "reply-to" rule when you create an incoming NAT/port forwarding. This works, and you can find it in rules.debug, but for some reason it doesn't seem to be executed correctly in all cases (not in my case atleast). What I did to correct the issue, was to make a floating rule, placed on top or near the top of the floating rules, that basicly exactly matches the auto-created interface firewall rule that the NAT/Port Forwarding rule generates. The only visible difference for me, is that this rule ends up much higher up in the rules.debug ruleset, but it makes all the difference - and suddently the portforwarding from a openVPN tunnel works perfectly.

One change I did:  When the upgrade came to 2.1 I checked the previously unchecked box asking that the master and backup synced via pfsync for OpenVPN.  So either something about the upgrade broke site-site or checking that box broke site-site. As a test, I unchecked the box and disabled the client and the server setup on the backup pf box, leaving them run on the master pf box on both the client and server ends of the site-site.  And… after a reboot... it works now. Site-Site OpenVPN does not like the openvpn HA pfsync box checked.  I suggest to check it during the configuration of the master, then before enabling the setup, save it disabled, so the backup PF box gets the config.  Then uncheck pfsyncing the OpenVPN, then enable the config on the master.  The good news is that it will work.  The bad news is that should the master go down you'll have to manually get up at 3 am to enable the config on the slave.  I think it is a rule that PFsense boxes only fail at 2:45 am.

No, I also cannot connect locally, though the openvpn services shows as running. Also tried to reboot PFSense, but no change.

@jimp: If you connect and then are disconnected a minute later, the most likely cause is having two clients connected with the same username/cert at the same time. When one connects, it will work for a minute, and then the other one will reconnect after 60 seconds and bump the first one off, and then it will work for 60 seconds until the first one reconnects and bumps it off, repeat, repeat, repeat… Hi, thx for the reposnse. I have try with windows, mac, linux, iphone, android, etc…. and the connection is very instable... In the GUI I view only one connection and I'm sure that the client try to conenct once. About 10 - 15 days ago the OpenVPN works perfectly...