use firewall rules to block or reject traffic in one or the other direction

Solved. I need add the rules in Float tab. As image attached. :) [image: floating.png] [image: floating.png_thumb]

Yeah the default gateway has to know how to reach that remote network.

Ping from the interface to the internet works fine ans the routing is in place. a pfsense to pf sense connection works fine it just appears to be layer 3 on the vpn connection that is failing zeroshell <-> pfsense

You can't. If pfSense doesn't handle the DHCP, there is no way it can know that information.

Actually in case #1 you probably wouldn't have a problem. When a road warrior connects, and talks on the VPN tunnel, the traffic from the client should be coming from its OpenVPN client IP, not the IP it obtained from the coffee shop network. In case #2 you would have a problem trying to reach anything in that subnet, yes. It would believe it was local. You could setup some 1:1 NAT for another unused subnet that people can use in that case though, like 172.20.11.0/24 that maps on the OpenVPN interface to 172.20.10.0/24 on the inside. Then if you have a conflict, the clients just connect to IPs in the alternate subnet. Though with that odd of a subnet I doubt you'd ever hit a coffee shop or hotel using that.

There isn't an automated way to make that many users+certificates. Even if you setup radius, unless you did auth-only, you'd still need certificates. Anyhow, I wouldn't consider 50-60 users "small", radius would work well for that size. There are freeradius packages for pfSense, though I'm not sure how easy it would be to add users to them in a batch (either freeradius or the new freeradius2 package)

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?