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.

@jader: Any news about pfSense2 authenticate against SME8 LDAP ? I'd like to have it running SquidProxy/DansGuard authenticated! Hi, I am interested in too… (pfSense v2.0.1) But can't get it working so far... But keep trying... Regards,

Hey guys, just so you know, I recently went through troubleshooting why my VPN connection was so slow (3Mbps on a 25Mbps link). I tried some of the recommendations in this thread and others, but nothing helped. Turns out I set the transport to TCP (bad) when I created the server. I switched to UDP and now I get fast speeds (nearly 25Mbps).

Apparently so. I guess I can chalk this one up as a good learning experience. Solution: Switch OpenVPN to UDP!

FYI- We have some of that procedure documented here: http://doc.pfsense.org/index.php/Using_EasyRSA_Certificates_in_2.x

the static routes are in place in pfSense, for example: 10.1.2.0/24 via 10.1.1.1 (L3 switch interface) 10.1.3.0/24 via 10.1.1.1 And I agree that my OpenVPN client might need to know those, assuming they aren't included in the config file I generated with the export utility. What I don't understand is why it was working briefly… and why I can't hit anything on the 10.1.1.0/24 network, which is where the pfSense inside interface is (10.1.1.254) and which should be routed automatically.

That makes sense, I'll try that.

you are my hero hahaha i thought that proxy authentication is the place where i put my user+pass IT WORKS :D thank you

heper, I tried setting up ospf as you described but for some reason the Quagga UI makes some changes that I didnt specify while ignoring other that I do. I have two openvpn tunnels. The tunnel networks are conn1: 10.1.1.12/30 and conn2:  10.1.1.16/30. The quagga will sometimes add those two networks as networks to distribute without me specifying them. So if conn1 is up while conn2 is down ospf will add a route to 10.1.1.18 via con1 and it will prevent the openvpn connection conn2 from coming online (openvpn client fails to add the route). Another issue i was having was being able to distribute the openvpn 'Remote Users' network via quagga. I have a 'Remote Users' openvpn server with network 10.2.2.0/24. I tried to add the network to be distributed via ospf but it only distributes the route 10.2.2.2/32 Oddly enough both these issues dont' appear when i use openospfd. Any help would be greatly appreciated. -E

Okay, I have this working now. I put the``` push "iroute 10.0.0.0 255.255.255.0" Ini order to register the phone I had to manually provision the phone. It will not auto-provision, I assume because pfsense doesn't pass the option 66 for TFTP to the Virtual Lan clients? Either that or OpenVPN doesn't support passing said option? Thanks for the help thermo!

Thank for you reply. This is my server config: dev ovpns1 dev-type tun dev-node /dev/tun1 writepid /var/run/openvpn_server1.pid #user nobody #group nobody script-security 3 daemon keepalive 10 60 ping-timer-rem persist-tun persist-key proto udp cipher AES-128-CBC up /usr/local/sbin/ovpn-linkup down /usr/local/sbin/ovpn-linkdown local x.x.x.x tls-server server 10.1.1.0 255.255.255.0 client-config-dir /var/etc/openvpn-csc tls-verify /var/etc/openvpn/server1.tls-verify.php lport 1194 management /var/etc/openvpn/server1.sock unix push "route 192.168.2.0 255.255.255.0" ca /var/etc/openvpn/server1.ca cert /var/etc/openvpn/server1.cert key /var/etc/openvpn/server1.key dh /etc/dh-parameters.1024 tls-auth /var/etc/openvpn/server1.tls-auth 0 comp-lzo route 192.168.88.0 255.255.255.0 10.1.1.2

Looks like it was just fixed– old archive on the package server, a simple uninstall and reinstall as of a few minutes ago fixes it.