Finally I found an answer for my issue in following article, that explains how to setup OpenVPN in bridged mode:

http://hardforum.com/showthread.php?t=1663797

Unfortunately it is not possible to do that remotely as the new configuration kicks off my current client connection. But that's a different issue.

brgds
David

From the pfSense OpenVPN Client config page, this should've given you a clue:

Tunnel Network: 10.1.0.1/24
Remote Network: 192.168.202.1/24

You entered host addresses instead of network addresses.  They need to be:

Tunnel Network: 10.1.0.0 (match the subnet mask to the tunnel network on your server. you have /24, but you typically see a /30 here)
Remote Network: 192.168.202.0/24

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.

:)

floating.png
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.