Is there a different default gateway set on this Windows server, another than the Vyatta?

The full log if it's of any help: Mar 29 09:39:22 openvpn 18498 Initialization Sequence Completed Mar 29 09:39:22 openvpn 18498 ERROR: FreeBSD route add command failed: external program exited with error status: 1 Mar 29 09:39:22 openvpn 18498 ERROR: FreeBSD route add command failed: external program exited with error status: 1 Mar 29 09:39:22 openvpn 17204 Initialization Sequence Completed Mar 29 09:39:22 openvpn 18498 /usr/local/sbin/ovpn-linkup ovpnc2 1500 1558 10.43.10.6 10.43.10.5 init Mar 29 09:39:22 openvpn 18498 /sbin/ifconfig ovpnc2 10.43.10.6 10.43.10.5 mtu 1500 netmask 255.255.255.255 up Mar 29 09:39:22 openvpn 18498 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0 Mar 29 09:39:22 openvpn 18498 ioctl(TUNSIFMODE): Device busy: Device busy (errno=16) Mar 29 09:39:22 openvpn 18498 TUN/TAP device /dev/tun2 opened Mar 29 09:39:22 openvpn 18498 TUN/TAP device ovpnc2 exists previously, keep at program end Mar 29 09:39:22 openvpn 17204 /usr/local/sbin/ovpn-linkup ovpnc1 1500 1558 10.51.10.6 10.51.10.5 init Mar 29 09:39:21 openvpn 17204 /sbin/ifconfig ovpnc1 10.51.10.6 10.51.10.5 mtu 1500 netmask 255.255.255.255 up Mar 29 09:39:21 openvpn 17204 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0 Mar 29 09:39:21 openvpn 17204 ioctl(TUNSIFMODE): Device busy: Device busy (errno=16) Mar 29 09:39:21 openvpn 17204 TUN/TAP device /dev/tun1 opened Mar 29 09:39:21 openvpn 17204 TUN/TAP device ovpnc1 exists previously, keep at program end Mar 29 09:39:19 openvpn 18498 [5ad846e5cc1f0de1b191851de6585c8b] Peer Connection Initiated with [AF_INET]209.222.23.62:1198 Mar 29 09:39:19 openvpn 18498 WARNING: 'cipher' is used inconsistently, local='cipher AES-128-CBC', remote='cipher BF-CBC' Mar 29 09:39:19 openvpn 18498 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1558', remote='link-mtu 1542' Mar 29 09:39:19 openvpn 18498 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this Mar 29 09:39:19 openvpn 18498 UDPv4 link remote: [AF_INET]209.222.23.62:1198 Mar 29 09:39:19 openvpn 18498 UDPv4 link local (bound): [AF_INET]82.16.99.44 Mar 29 09:39:19 openvpn 17204 [6c8636367fc1b43d257d7e0b8008e2ad] Peer Connection Initiated with [AF_INET]108.61.122.221:1198 Mar 29 09:39:19 openvpn 17204 WARNING: 'cipher' is used inconsistently, local='cipher AES-128-CBC', remote='cipher BF-CBC' Mar 29 09:39:19 openvpn 17204 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1558', remote='link-mtu 1542' Mar 29 09:39:19 openvpn 17204 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this Mar 29 09:39:18 openvpn 17204 UDPv4 link remote: [AF_INET]108.61.122.221:1198 Mar 29 09:39:18 openvpn 17204 UDPv4 link local (bound): [AF_INET]82.16.99.44 Mar 29 09:39:14 openvpn 18498 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Mar 29 09:39:14 openvpn 18498 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info. Mar 29 09:39:14 openvpn 18213 WARNING: file '/var/etc/openvpn/client2.up' is group or others accessible Mar 29 09:39:14 openvpn 18213 library versions: OpenSSL 1.0.1s-freebsd 1 Mar 2016, LZO 2.09 Mar 29 09:39:14 openvpn 18213 OpenVPN 2.3.14 amd64-portbld-freebsd10.3 [SSL (OpenSSL)] [LZO] [MH] [IPv6] built on Feb 15 2017 Mar 29 09:39:13 openvpn 17204 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Mar 29 09:39:13 openvpn 17204 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info. Mar 29 09:39:13 openvpn 17106 WARNING: file '/var/etc/openvpn/client1.up' is group or others accessible Mar 29 09:39:13 openvpn 17106 library versions: OpenSSL 1.0.1s-freebsd 1 Mar 2016, LZO 2.09 Mar 29 09:39:13 openvpn 17106 OpenVPN 2.3.14 amd64-portbld-freebsd10.3 [SSL (OpenSSL)] [LZO] [MH] [IPv6] built on Feb 15 2017 Mar 29 09:39:13 openvpn 14626 Initialization Sequence Completed Mar 29 09:39:13 openvpn 14626 UDPv4 link remote: [undef] Mar 29 09:39:13 openvpn 14626 UDPv4 link local (bound): [AF_INET]82.16.99.44:1194 Mar 29 09:39:13 openvpn 14626 /usr/local/sbin/ovpn-linkup ovpns3 1500 1558 10.8.0.1 255.255.255.0 init Mar 29 09:39:12 openvpn 14626 /sbin/ifconfig ovpns3 10.8.0.1 10.8.0.2 mtu 1500 netmask 255.255.255.0 up Mar 29 09:39:12 openvpn 14626 do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=0 Mar 29 09:39:12 openvpn 14626 ioctl(TUNSIFMODE): Device busy: Device busy (errno=16) Mar 29 09:39:12 openvpn 14626 TUN/TAP device /dev/tun3 opened Mar 29 09:39:12 openvpn 14626 TUN/TAP device ovpns3 exists previously, keep at program end Mar 29 09:39:12 openvpn 14626 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Mar 29 09:39:12 openvpn 14313 library versions: OpenSSL 1.0.1s-freebsd 1 Mar 2016, LZO 2.09 Mar 29 09:39:12 openvpn 14313 OpenVPN 2.3.14 amd64-portbld-freebsd10.3 [SSL (OpenSSL)] [LZO] [MH] [IPv6] built on Feb 15 2017

Beside routing, you may want to check firewall rule on both Site A and Site B. It would be easier for comment if you share current configuration.

@johnpoz: "30 seconds of work adds an extra layer of security. " Sorry it doesn't - that is not how security works in IT.. Let me guess you also hide your SSID or don't broadcast it and use mac address filtering.. Since they are added layers of security? ;)  Do you also turn off your dhcp server as another layer? But yeah those keep grandma from hacking your wifi ;) No, I stand by my answer. The snark is irrelevant. Making something a little more difficult is good planning. The real security is not impaired if some nuisance security is tossed into the mix. It just makes brittle snobs all huffy.

You would enter the fully qualified domain name (e.g. hostname.domain.com) - Whatever hostname is in DNS that points to the firewall on the address used by OpenVPN

Hi Old but hey! Seems your VPN Provider has been possibly marked as been known for Fraud or Fraudulent Attempts in the past or current, so they may ear mark it for "Further Authentication" to mitigate these attacks,. Failing that, it could be due to the way your VPN & your Machine handles the Certificate that the site provides. Hope this helped.

Thanks Jim!

Oh that did it..thanks.  I thought that would have broken my policy based routing as well but it seems to still work.

RADIUS is not encrypted. The protocol doesn't have any mechanism for it. You can use things like MSCHAPv2 to protect the actual passwords and credentials in transit though. But you have to handle the encryption between RADIUS server and client yourself (e.g. VPN)

Hi Jimp, I did use command "redirect-gateway def1" as attached capture, but no route for 0.0.0.0/1 and 128.0.0.0/1 were added as you can see in capture #2. Could you pls advise correct way to apply that command? Thank you very much. [image: WithRedirectGW1.PNG] [image: WithRedirectGW1.PNG_thumb] [image: WithRedirectGW2.PNG] [image: WithRedirectGW2.PNG_thumb]

Works for me, although RDP is a little sketchy at times. It works perfectly on one PC but sometimes has problems connecting to another. Try playing around with the network file sharing and control panel settings. They can be annoying. TeamViewer works fine; I have it set to access over local lan exclusively. Occasionally I use TV over the internet but use a complex very long custom password. Usually it's access over local lan only. Once you're on the local lan, use RDP and connect using the IP address: for example 192.168.1.xxx, not using the pc name such as PC123. In fact, I use it extensively on occasion. My 12 inch android tablet has a RDP client program. Since most hotel internet is slow, I can use the home server as the main processor and only need to use the hotel internet to talk to the home laptop. That's all.

Works for me. I had my issues figuring out OpenVPN but eventually got it working. The problem was me coming in from DD-WRT where things are more complicated. pfSense OpenVPN is so easy to get working as a server that I needed to unlearn a lot and I was fairly stubborn about it. It should work. If you can access your network remotely using OpenVPN you should be able to access a Plex server. Just for fun, try using OpenPHT as your PC plex client. The full standard Plex program has issues I didn't care to research that OpenPHT does not have. Android Plex works fine enough for me to consider actually buying a license.

@claes_hellgren: @petros: Hi Guys Here is how I got it working. 1. Disable Automatic NAT as you suggested. I created a NO NAT rule for the OpenVPN interface. 2. Created a static mapping in the local WINS database for the remote Domain Controller. 3. Go to Sites and Services on the remote DC and make sure there is a connector set for the local DC in the NTDS settings. 4. Go to Sites and Services on the local DC and make sure there is a connector set for the remote DC in the NTDS settings. Thanks for the help. How dose your NO NAT rule look? The topic is old but it does help me for the same situation. I just disable Automatic NAT as suggested and change to Manual Outbound NAT rule generation  (AON - Advanced Outbound NAT). A NO NAT rule may not needed but if you want just select the option "Do not NAT Enabling this option will disable NAT for traffic matching this rule and stop processing Outbound NAT rules". I just try with or without NO NAT rule, both DC replicated without issue.

well i could not find anything either thanks for reading any that did. i worked around the issue by turning off transparent proxy and blocking http at firewall for all other networks except my own trusted and on that one i have two web browsers now one configured for squid the other not. so browser one is going through proxy second browser goes via VPN without leaking. i am going to try and configure wpad so i don't have to manually configure browsers, its not perfect but anyone finding themselves in same situation at least you can have a semi work around. thanks all

Haha yes sir it is. Still, there is zero question that ISP is selling everything they can about you. They all do it so there is effectively a monopoly, their business is not affected when people know they are doing this. VPN providers very well may do this, some have been caught doing so, but it is bad for their business if they are found doing this. VPS providers I'm guessing probably do not engage in this activity much as they often serve large companies that would and could fight their data being sold. Both options at least have the potential for improvement over ISP.

Unfortunately my partner rebooted the system whilst I was away so I'll have to wait another couple of weeks to pull logs.

Under LAN of Site A. I tried setting rule: SRC * DST * DSTPort 25 GW OPTVPN That looks reasonable. and also SRC Port 25 DST * DSTPort * GW OPTVPN Setting a source port is almost never right, and is certainly not right in this case. I have no problem routing inbound internet traffic -> 99.99.99.99:STMP to 10.10.0.15 So if that is the case, you want to check: The rules on the OpenVPN tab/interface at Site B to be sure the traffic is allowed from site A (10.10.0.15) to any You have outbound NAT in place on WAN at site B for the 10.10.0.15 source address. That is also where you would specify 99.99.99.99 as the source address if there is more than one choice.

Done! thanks