That probably a holdover from the old design when OpenVPN used to be a package. If someone wants to add that other setting as a column, feel free to submit a patch. There's no technical reason it can't be there. There is plenty of room on that line to add another column, or the disabled column could be removed if someone makes it grey out the line (like it does for disabled items elsewhere in the GUI).

Sorry I got distracted with Easter stuff. I'll get it together ASAP I promise :D. Edit: Ok this should work.LINK Copying and pasting from word to here mangled the formatting. If that works for you, I'll make a new post and redo the formatting for the forum.

you're not permitting the client traffic server-side in firewall rules. What I would have guessed anyway, but maybe I'm psychic and know that fixed your issue, and gave you the suggestion in the first place.  ;) http://serverfault.com/questions/377399/pfsense-peer-to-peer-openvpn-not-connecting

I found a way to set one of the dsl modems in bridged mode and now it works!

Try the latest revision of the package.

@ichtus: if i use the name from CAs not working if i use the name from certificates not working Go to certificates -> create a cert (for testing) and scroll down. there you will find the field "Common name". That's it. Every cert has a common name.

Ok this is like pulling teeth.  I think I want to change the strategy here.  Maybe what I should do: Route the external /28 through the VPN link rather than trying to NAT it through Setup the CARP VIPs for that /28 on the Location B firewall instead NAT only from the Location B firewall external to internal interfaces Does anyone see an issue with this logically?

You should configure your VPN as a bridged, not a routed, VPN. That'll make it much easier to get DLNA working.

Thank You! I was going to post about this issue, but I always use "auth-nocache" option as recommended by OpenVPN client :) I was thinking this is about communication issue (temporary time-out) or so. Or I was going to use TCP instead of UDP to fix this.

That is awesome.  Thank you very much.  I had everything but the route on the box 2.  I added the route, and it started talking immediately.  I can't thank you enough.

@jimp: It's more accurate to say: You can't effectively override the management behavior. However, if you can't, that's a bug in OpenVPN not a bug in our config […] If you add a second management line (via advanced options) and it ignores your IP or port, that's OpenVPN misinterpreting your config. It will typically just take the last line that matches. If it's adding them together it's inconsistent. Thank you Jimp! Now this becomes clearer: OpenVPN apparently starts treating everything in any management directive as unix domain socket, as soon as this mode is activated once. I'll report this inconsistency to openVPN. Maybe a fix can make it into the upcoming 2.3! @jimp: ncat -l -k -p 5001 -c 'nc -U /var/etc/openvpn/server1.sock' I wrote a plugin that reads the openvpn status php. Gave me some ideas, I'll work more on this when I have time. Thanks again! Chris

@Nachtfalke: You run the OpenVPN client as an user with admin rights ? The Windows client - does it allow connections/pings from other hosts on other subnets ? Try diabling the firewall on the client. Add an "any to any" firewall rule on the pfsense firewall OpenVPN tab. For better troubleshooting, I connected using a Linux laptop, I think I see the route problem: The LAN I'm connecting to is 192.168.2.0, client PTP is 192.168.11.5, client IP is 192.168.11.6 From the Linux laptop connected this is the "route" output: Destination    Gateway                Genmask              Flags  Metric Ref    Use  Iface 192.168.11.5    *                          255.255.255.255  UH      0        0        0    tun0 192.168.11.1    192.168.11.5      255.255.255.255  UGH  0        0        0    tun0 192.168.11.0    192.168.11.5      255.255.255.0      UG      0        0        0    tun0        < wrong ?? 192.168.1.0      *                          255.255.255.0      U        303    0        0    eth1 loopback          *                          255.0.0.0              U        0        0        0    lo default              Wireless_Broadb 0.0.0.0                  UG    303    0        0    eth1 I think the 'wrong' line should be: 192.168.2.0      192.168.11.5      255.255.255.0      UG      0        0        0    tun0 So if I type the command: route add -net 192.168.2.0 netmask 255.255.255.0 gw 192.168.11.5 Now it works, I can ping the firewall which is 192.168.2.6 and other machines on the LAN 192.168.2.0 So, is that line wrong?  If so, what can I do?  Or am I completely on the wrong track here? Julien OK everyone, never mind.  I just looked at my advanced options and I had 192.168.2.11 and the route being pushed. I changed it to: push "route 192.168.2.0 255.255.255.0";  and now it works. So I'm thinking, the Local Network has to be blank and the "Advance Configuration" has to have a push?

@jimp: It should all work fine though with that redirect-gateway def1 on there it may be doing something funny like sending traffic back via that other tunnel instead of directly. I have now double checked this and here are my findings. What I need to be able to do before it's working for my needs, are all of the below: a. tunnel working for outbound traffic b. tunnel being able to handle directing outbound traffic via fw rules (policy routing) c. tunnel being able to accept incoming traffic, just like the WAN,   being able to run a SMTP service behind the tunnel for instance. This means you can   (must) add port forwards and fw rules. I have ordered and set up a test tunnel. (I'm skipping most of the setup stuff) I disable/enable client config, triggering the tunnel to be set up. These routing entries are added: 0.0.0.0/1 10.8.6.245 UGS 0 13 1500 ovpnc3 => 10.8.6.241/32 10.8.6.245 UGS 0 11 1500 ovpnc3 10.8.6.245 link#15 UH 0 0 1500 ovpnc3 10.8.6.246 link#15 UHS 0 0 16384 lo0 128.0.0.0/1 10.8.6.245 UGS 0 33 1500 ovpnc3 My local IP is 10.8.6.246 Tunnel remote endpoint is 10.8.6.245 Tunnel GW is 10.8.6.241 I am unsure whether the advice given on the forum to choose the type of GW to "none" is the most correct one. I think I got it working using that setting though. I rather quickly got outbound traffic working but inbound seems more uncertain than in 1.2.3, at least that's my assertion right now. I have set up (as i did on 1.2.3) a GW with static IP, 10.8.6.246 in this case. So basically what you do is look at the pushed info from the server side and add the local IP as the static IP address. openvpn[14144]: PUSH: Received control message: 'PUSH_REPLY,route-delay 2,route-metric 1,dhcp-option DNS n1.nn.nn.nn,dhcp-option DNS n2.nn.nn.nn,route 10.8.6.241,topology net30,ping 10,ping-restart 60,ifconfig 10.8.6.246 10.8.6.245' NOW: pinging in from the outside works. And connecting to a mail server works. NOTE: I have now NOT removed the routing entries being added. However now all PCs are being pushed through the tunnel. I now add an explicit rule forcing this one PC I'm testing on, to use the default GW instead, I even reset states to be sure. It still is pushed through the tunnel. The fw rule is not having any effect. The only way I can get the fw rules to do their job is to remove the first and last entries above. NOW: I remove the route entries. I don't reset states. EFFECTS ARE: 1. policy routing now immediately starts working. I can force the PC by fw rules to use EITHER default or strongvpn gw 2. Inbound traffic stops working. All of a sudden I can't ping in or reach the mail server. I don't really see the logic in "2" happening here. Just to test it I reset states. No different. I don't restart (can selldom restart this machine on the fly due to other users) The "2" from above is AFAICT different from 1.2.3. I useed this exact procedure to get all a/b/c above working, but seem not to be able to do so in 2.0.1. So, it looks like it's either: 1. all outbound traffic through tunnel and inbound traffic working OR 2. policy routing enabled for outbound traffic and no inbound traffic INBOUND traffic above is referring to traffic INITIATED from the outside. I'm hoping I'm missing something here and it's possible to get it working in 2.0.1. I do know that all these features were working in my 1.2.3 setup.

If you select the duplicate option, that will work. It's a bad idea though, if the certificate is ever compromised you'll have to reissue clients to everyone instead of just sticking the compromised certificate in a CRL.

Please do not cross-post (post the same thing in multiple boards). If you don't know where your topic belongs, use a general category instead of a specific one.

yes it's possible as you describe.

Thanks…

Unfortunately there isn't a way to do that by web site. You could do it by subnet/IP address but sites like that use so many different addresses and CDNs that it's impossible to specify them in any definitive fashion.

I should have replied back to let everyone know, I fixed this with the above solution a couple of days ago. The one thing I will tell you, is that if you rely on a firewall to access the machine you will be in deep trouble if you reboot it. If you ever come across this problem you need to fix it before you restart the machine.