I solved it. Anyone running into this problem: On SERVEER PFSENSE you new to enable advanced routing(AON). On that screen once you activate you will see rules. Copy the rule for open vpn, and replace it wil the IP range of PCs behind the Pfsense  client. Unline DD-WRT, pfsense does not do NAT on OpenVPN which is great :-)

The OpenVPN server is the same as on other distributions. There is no (major) difference between. The only advantage I see on pfsense is the GUI which is easy to use and you do not hneed extra hardware, extra port forward because all is on the same machine. And you can easily see which user is logged in, you can enable firewall logging on this user, you can discconect a user and so on.

It seems that you have: WAN IP 192.168.1.50/24 - gateway 192.168.1.1 LAN IP 192.168.1.2/24 Normally there are bigger problems than VPN when I accidentally get WAN and LAN subnets the same. Usually I can't even access the WebGUI from LAN. First thing is to make your LAN a different subnet - e.g. 192.168.2.1/24 Then the ordinary routing will work, and maybe when the VPN connects it will do something useful. If you want/need to access your pfSense from what is its WAN side (which is actually behind your other router and cable modem), then you can easily add pass rules on WAN to do that.

In this config you can't access from pfsense subnet to dd-wrt router to manage via web or ping, only telnet. But some code maybe added to dd-wrt router firewall script: iptables -I INPUT 3 -i tun0 -p icmp -j ACCEPT iptables -I INPUT 1 -i tun0 -p tcp –dport 80 -j ACCEPT and saved.

Given that none of those log entries indicate it fully established a connection, I'd say you're either pointing it at the wrong server IP, the firewall rules on the server end are blocking the traffic, or something in between is blocking the traffic.

That does sound like the kind of things we see where switches or related gear refuse to talk outside their own subnet. I was on a conference call with a customer last week with them and their switch vendor and even though they had everything set correctly (gateway, subnet mask, etc) and the switch vendor said there were no such filters, it still refused to allow access to the switch GUI from outside its own subnet. Add a little manual outbound NAT on that interface to make the traffic going to those devices appear to originate from its own subnet and it works fine.

Thanks guys, I too was missing the static route back into the vpn subnet. It works great now with using just the wan interface.

it is certainly possible to set it up that way. personally i just create a openvpn instance for each site. In case of trouble/other configuration/new routes/… i only want the site involved to temporary lose it's connection and not every site connected.

One or more certificates weren't generated correctly. Upgrade to 2.x and use the built-in cert manager, it's much, much easier to generate certs with.

Yes. As long as you dont have overlapping subnets in the different locations it will be no problem. Just make sure that you have in all places the correct routes.

it works now! thx!

Where exactly are you using pfSense in your setup? If it is a general question about OpenVPN or VNC you may find more users that can help you in the OpenVPN forums [1], TightVNC mailing-list [2] or UltraVNC forum [3]. [1] https://forums.openvpn.net/ [2] https://lists.sourceforge.net/lists/listinfo/vnc-tight-list [3] https://forum.ultravnc.net/

you had the OpenVPN server or client bound to a virtual IP that needs to be changed to one of your new ISP's IPs. How can I make changes to it? your firewall rule permitting traffic to the OpenVPN server instance from the client instance now has the wrong source or destination IP (depending on whether the server or client side changed). We didn't specify the rule for outgoing connection so it's pretty much open. Source * to Destination * your client config needs to change server IPs to the new ISP, if the server side is the one that changed. The source IP is changing, how can I change the server IP on the client side?

Does it help if you run the openvpn client as administrator? (right click on VPN shortcut and then run as administrator)

Thanks.  That makes sense… I think  ;) Im obviously not a networking guru but I have learned alot with this project alone. I got bridging to work.  I had troubles with routes (imagine that) when using different subnets.  I put both sites on the same subnet and bridging is working beautifully.  In fact Im amazed - it really is like being plugged into the same l2 switch.  I put a test pc from site B (client) onto the domain at site A (server), mapped network drives, sql data sources, networked printers, the works.  Local DNS and DHCP even work.  Very, very cool. As always Im grateful for the help, and now hooked on pfsense!  Time to go shopping for some 1U bare bones…

If the test uses a fixed TCP window size, then the bandwidth achieved will be limited by the combination of window size and round-trip delay. e.g. the window size above is 64.2KByte. That means that the test will send 64.2KByte of data, then stop sending until it gets an ACK from the 1st packet…. - never having more than 64.2KByte of unacknowledged data. For example, if your round-trip delay (latency) is 100ms (0.1sec) then the maximum throughput on TCP is: 64.2KByte10248bits / 0.1 sec = 5,259,260 bits/sec Try using a bigger window size, that might help the test if the latency from client is high. Of course, your Alix 2D13 might be max'd out anyway.