Openvpn server not starting (road warrior configuration)
-
Your tunnel network MUST be a different subnet of private IP addresses to anything else in your network.
You will also need to be port-forwarding the public IP port 1195 on the front-end ZyXEL to the pfSense WAN IP, allowing that with a pfSense firewall rule.
When doing the client export, you need to make sure to export with the public IP, not the (private) Interface IP address - the clients out in real-internet-land have to connect to the public IP, which then gets forwarded inside your private network.
If your network is not already too big, then take the time now to pay attention to the note about "extremely common subnet address" - change all the internal network to some other set of private IP subnets.Phil,
Took me a while to get this moving again but I've made the changes you suggested and OpenVPN server is starting ok but I can't get the clients to connecrt (Vista, Windows 7 & Andriod).
Any idea?
OpenVPN config file on the Vista Desktop
dev tun persist-tun persist-key cipher BF-CBC tls-client client resolv-retry infinite remote 184.x.xxx.xxx 1195 udp tls-remote mkwestmark auth-user-pass pkcs12 blm-firewall-udp-1195-mkwestmark.p12 tls-auth blm-firewall-udp-1195-mkwestmark-tls.key 1 comp-lzo
OpenVPN Desktop Log File
Tue Jul 30 18:44:04 2013 OpenVPN 2.2.0 i686-pc-mingw32 [SSL] [LZO2] [PKCS11] [IPv6 payload 20110521-1 (2.2.0)] built on May 21 2011 Enter Management Password: Tue Jul 30 18:44:11 2013 WARNING: Make sure you understand the semantics of --tls-remote before using it (see the man page). Tue Jul 30 18:44:11 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables Tue Jul 30 18:44:12 2013 Control Channel Authentication: using 'blm-firewall-udp-1195-mkwestmark-tls.key' as a OpenVPN static key file Tue Jul 30 18:44:12 2013 LZO compression initialized Tue Jul 30 18:44:12 2013 UDPv4 link local (bound): [undef]:1194 Tue Jul 30 18:44:12 2013 UDPv4 link remote: 184.x.xxx.xxx:1195 Tue Jul 30 18:45:12 2013 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Tue Jul 30 18:45:12 2013 TLS Error: TLS handshake failed Tue Jul 30 18:45:12 2013 SIGTERM[soft,tls-error] received, process exiting
pFsense OpenVPN Log
Last 50 OpenVPN log entries Jul 30 17:13:55 openvpn[14268]: /sbin/ifconfig ovpns1 192.168.200.1 192.168.200.2 mtu 1500 netmask 255.255.255.255 up Jul 30 17:13:55 openvpn[14268]: /usr/local/sbin/ovpn-linkup ovpns1 1500 1542 192.168.200.1 192.168.200.2 init Jul 30 17:13:55 openvpn[18537]: UDPv4 link local (bound): 192.168.0.135:1195 Jul 30 17:13:55 openvpn[18537]: UDPv4 link remote: [undef] Jul 30 17:13:55 openvpn[18537]: Initialization Sequence Completed Jul 30 17:13:55 openvpn[18537]: IPv6 in tun mode is not supported in OpenVPN 2.2 Jul 30 17:19:04 openvpn[18537]: event_wait : Interrupted system call (code=4) Jul 30 17:19:04 openvpn[18537]: /usr/local/sbin/ovpn-linkdown ovpns1 1500 1542 192.168.200.1 192.168.200.2 init Jul 30 17:19:04 openvpn[18537]: SIGTERM[hard,] received, process exiting Jul 30 17:19:04 openvpn[48419]: OpenVPN 2.2.2 i386-portbld-freebsd8.1 [SSL] [LZO2] [eurephia] built on Apr 2 2013 Jul 30 17:19:04 openvpn[48419]: NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x. Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet. Jul 30 17:19:04 openvpn[48419]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Jul 30 17:19:04 openvpn[48419]: Control Channel Authentication: using '/var/etc/openvpn/server1.tls-auth' as a OpenVPN static key file Jul 30 17:19:04 openvpn[48419]: TUN/TAP device /dev/tun1 opened Jul 30 17:19:04 openvpn[48419]: /sbin/ifconfig ovpns1 192.168.200.1 192.168.200.2 mtu 1500 netmask 255.255.255.255 up Jul 30 17:19:04 openvpn[48419]: /usr/local/sbin/ovpn-linkup ovpns1 1500 1542 192.168.200.1 192.168.200.2 init Jul 30 17:19:04 openvpn[49556]: UDPv4 link local (bound): 192.168.0.135:1195 Jul 30 17:19:04 openvpn[49556]: UDPv4 link remote: [undef] Jul 30 17:19:04 openvpn[49556]: Initialization Sequence Completed Jul 30 17:23:09 openvpn[49556]: event_wait : Interrupted system call (code=4) Jul 30 17:23:09 openvpn[49556]: /usr/local/sbin/ovpn-linkdown ovpns1 1500 1542 192.168.200.1 192.168.200.2 init Jul 30 17:23:09 openvpn[49556]: SIGTERM[hard,] received, process exiting Jul 30 17:30:01 openvpn[62906]: OpenVPN 2.2.2 i386-portbld-freebsd8.1 [SSL] [LZO2] [eurephia] built on Apr 2 2013 Jul 30 17:30:01 openvpn[62906]: NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x. Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet. Jul 30 17:30:01 openvpn[62906]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Jul 30 17:30:01 openvpn[62906]: Control Channel Authentication: using '/var/etc/openvpn/server1.tls-auth' as a OpenVPN static key file Jul 30 17:30:01 openvpn[62906]: TUN/TAP device /dev/tun1 opened Jul 30 17:30:01 openvpn[62906]: /sbin/ifconfig ovpns1 192.168.200.1 192.168.200.2 mtu 1500 netmask 255.255.255.255 up Jul 30 17:30:01 openvpn[62906]: /usr/local/sbin/ovpn-linkup ovpns1 1500 1542 192.168.200.1 192.168.200.2 init Jul 30 17:30:01 openvpn[366]: UDPv4 link local (bound): 192.168.0.135:1195 Jul 30 17:30:01 openvpn[366]: UDPv4 link remote: [undef] Jul 30 17:30:01 openvpn[366]: Initialization Sequence Completed
OpenVPN System Log
ul 30 17:17:09 dnsmasq[46766]: ignoring nameserver 127.0.0.1 - local interface Jul 30 17:17:12 php: : Resyncing OpenVPN instances for interface PUBLICWIFI. Jul 30 17:17:12 php: : Creating rrd update script Jul 30 17:17:17 apinger: ALARM: PublicWifiGW(10.0.0.1) *** down *** Jul 30 17:17:20 ntpdate[1017]: adjust time server 199.102.46.72 offset -0.017006 sec Jul 30 17:17:20 php: : pfSense package system has detected an ip change 192.168.2.1 -> 192.168.211.1 ... Restarting packages. Jul 30 17:17:20 check_reload_status: Starting packages Jul 30 17:17:22 php: : Restarting/Starting all packages. Jul 30 17:17:27 check_reload_status: Reloading filter Jul 30 17:18:07 apinger: Error while feeding rrdtool: Broken pipe Jul 30 17:18:07 apinger: rrdtool respawning too fast, waiting 300s. Jul 30 17:19:04 kernel: ovpns1: link state changed to DOWN Jul 30 17:19:04 check_reload_status: Reloading filter Jul 30 17:19:04 kernel: ovpns1: link state changed to UP Jul 30 17:19:04 check_reload_status: rc.newwanip starting ovpns1 Jul 30 17:19:06 php: : rc.newwanip: Informational is starting ovpns1. Jul 30 17:19:06 php: : rc.newwanip: on (IP address: 192.168.200.1) (interface: ) (real interface: ovpns1). Jul 30 17:19:09 ntpdate[55965]: adjust time server 199.102.46.72 offset 0.012485 sec Jul 30 17:19:09 php: : pfSense package system has detected an ip change -> 192.168.200.1 ... Restarting packages. Jul 30 17:19:09 check_reload_status: Starting packages Jul 30 17:19:11 php: : Restarting/Starting all packages. Jul 30 17:22:28 check_reload_status: Syncing firewall Jul 30 17:23:02 check_reload_status: Syncing firewall Jul 30 17:23:09 kernel: ovpns1: link state changed to DOWN Jul 30 17:23:09 kernel: ovpns1: changing name to 'tun1' Jul 30 17:23:09 check_reload_status: Reloading filter Jul 30 17:23:19 check_reload_status: Syncing firewall Jul 30 17:24:40 check_reload_status: Syncing firewall Jul 30 17:24:52 check_reload_status: Syncing firewall Jul 30 17:25:22 check_reload_status: Syncing firewall Jul 30 17:26:35 check_reload_status: Syncing firewall Jul 30 17:27:18 php: /system_usermanager.php: Tried to remove user but got user pw instead. Bailing. Jul 30 17:27:19 php: /system_usermanager.php: The command '/usr/sbin/pw groupmod admins -g 1999 -M 0,2003 2>&1' returned exit code '67', the output was 'pw: user `2003' does not exist' Jul 30 17:27:19 check_reload_status: Syncing firewall Jul 30 17:28:59 check_reload_status: Syncing firewall Jul 30 17:29:54 check_reload_status: Syncing firewall Jul 30 17:30:01 php: /wizard.php: The command '/sbin/ifconfig ovpns1' returned exit code '1', the output was 'ifconfig: interface ovpns1 does not exist' Jul 30 17:30:01 check_reload_status: Reloading filter Jul 30 17:30:01 kernel: tun1: changing name to 'ovpns1' Jul 30 17:30:01 kernel: ovpns1: link state changed to UP Jul 30 17:30:01 check_reload_status: rc.newwanip starting ovpns1 Jul 30 17:30:04 php: : rc.newwanip: Informational is starting ovpns1. Jul 30 17:30:04 php: : rc.newwanip: on (IP address: 192.168.200.1) (interface: ) (real interface: ovpns1). Jul 30 17:30:06 ntpdate[6610]: adjust time server 199.102.46.72 offset -0.017473 sec Jul 30 17:30:06 php: : pfSense package system has detected an ip change -> 192.168.200.1 ... Restarting packages. Jul 30 17:30:06 check_reload_status: Starting packages Jul 30 17:30:08 php: : Restarting/Starting all packages. Jul 30 17:38:14 check_reload_status: Reloading filter Jul 30 17:54:28 php: /index.php: Successful webConfigurator login for user 'admin' from 192.168.183.26 Jul 30 17:54:28 php: /index.php: Successful webConfigurator login for user 'admin' from 192.168.183.26
-
Tue Jul 30 18:44:12 2013 UDPv4 link local (bound): [undef]:1194 Tue Jul 30 18:44:12 2013 UDPv4 link remote: 184.x.xxx.xxx:1195 Tue Jul 30 18:45:12 2013 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Tue Jul 30 18:45:12 2013 TLS Error: TLS handshake failed
The 60 seconds thing usually means that there was simply no response from the server at 184.x.xxx.xxx:1195 - usually because the client "hello" to start the protocol off never gets to the server.
I can't see anything obviously wrong with your configs, so the missing piece of evidence is a port forward from the ZyXEL public IP into the pfSense WAN 192.168.0.135:1195 where the OpenVPN server is listening.
Either:
a) stare at the ZyXEL config screens until you spot the problem, and/or:
b) do some packet capture at the ZyXel (no idea about that) looking for packets to 184.x.xxx.xxx:1195 and also do packet capture at pfSense looking for packets to 192.168.0.135:1195
c) Look in the pfSense Firewall log, in case anything is being dropped (but your pass rule looks OK)
Once you know how far the packets get, then you can work on getting them further… -
The port forwarding was not working in any configuration. Looks like CenturyLink and ZyXel have some issues:
http://www.dslreports.com/nsearch?q=&q=PK5001Z+&sa=Go
Will respond back after I get them to replace my model.
-jay
-
Will respond back after I get them to replace my model.
Why not just replace it all with pfSense?
Everything is much simpler if you use the same high-quality software throughout your network :) -
I'm struggling with this. Are you saying " turn off the nat & routing functions in the ZyXel?"
Will respond back after I get them to replace my model.
Why not just replace it all with pfSense?
Everything is much simpler if you use the same high-quality software throughout your network :) -
I'm struggling with this. Are you saying " turn off the nat & routing functions in the ZyXel?"
Yes, definitely.
-
I'm struggling with this. Are you saying " turn off the nat & routing functions in the ZyXel?"
Yes, definitely.
Would I need to make changes in the firewall and/or NAT on 192.168.0.135 ?
-j
-
I was just having a laugh, because there don't seem to be any realistic hardware options that have native ADSL interfaces (a board with a telephone line jack) and run pfSense - if such things were easily available we would all be able to sleep easy not messing about with some front-end modem device that may or may not do NAT itself, port forward, route, may or may not go into bridge mode…
But yes, if the ZyXel can go into bridge mode and just pass through the real external public IP, then life is so much easier at the pfSense end. It can make the connection to the ISP directly itself and can see and deal with all traffic directly.
I have no idea about ZyXel and bridge mode, so make sure you have some confidence that you could put settings back the way they are, before you change stuff and your internet access is completely screwed!
Another thing I did recently on some TP-Link and Digicom ADSL devices was to not do specific port forwarding in to the pfSense WAN. They had a place to put a "DMZ IP". I put the pfSense WAN IP in there. It forwarded all traffic from the ADSL public IP to the pfSense WAN IP - like doing 1:1 NAT, plus ICMP and everything. Then I could open whatever ports I needed, and also block and log bad things at pfSense if I want to know who is port-scanning me from where...
Maybe the ZyXel has a similar option to forward everything, and it might work.
-
Would I need to make changes in the firewall and/or NAT on 192.168.0.135 ?
If you get the ZyXel into bridge mode, then pfSense WAN will end up with the real public IP. But mostly your firewall rules that open up incoming things refer to destination WAN Address, so pfSense does the right thing underneath to make pf rules for whatever "WAN Address" currently is.
-
But yes, if the ZyXel can go into bridge mode and just pass through the real external public IP, then life is so much easier at the pfSense end. It can make the connection to the ISP directly itself and can see and deal with all traffic directly.
I have no idea about ZyXel and bridge mode, so make sure you have some confidence that you could put settings back the way they are, before you change stuff and your internet access is completely screwed!
Definitely possible - I've done this with multiple Zyxel xDSL "modems" usually supplied by the ISPs here.
-
Kids are back in school and this project finally made it back on my list of things to do.
I figured out how to put the zyxel into transparent bridge mode - http://www.youtube.com/watch?v=eu1YDchv8uc
Currently the zyxel is configured with a static IP. If I put the zyxel into bridge mode, what changes do I need to make on the pfsense WAN port?
ZyXel Config: Modem IPv4 Address: 104.1.54.174 Modem IPv4 Subnet Mask: 255.255.255.128 DNS Address #1: 67.232.255.222 DNS Address #2: 67.232.255.218 Remote Gateway Address: 104.1.54.129
?
-
WARNING: potential conflict between –local address [192.168.0.135] and –ifconfig address pair [192.168.0.1, 192.168.0.2] – this is a warning only that is triggered when local/remote addresses exist within the same /24 subnet as --ifconfig endpoints. (silence this warning with --ifconfig-nowarn)
-
What should I do to address that?
@kejianshi:WARNING: potential conflict between –local address [192.168.0.135] and –ifconfig address pair [192.168.0.1, 192.168.0.2] – this is a warning only that is triggered when local/remote addresses exist within the same /24 subnet as --ifconfig endpoints. (silence this warning with --ifconfig-nowarn)
-
You should move your network ip for the server and the openvpn subnet to something fairly random and unique. Pick something like 10.94.113.1
like 10.x.x.1 for LAN ip and 10.x.x.0/24 for openvpn subnet.
Substitute numbers between 10 and 250 for the Xs.
-
That makes sense. Will make the changes this week. Do you think that's what is preventing the OpenVPN client from accessing the server? @kejianshi:
You should move your network ip for the server and the openvpn subnet to something fairly random and unique. Pick something like 10.94.113.1
like 10.x.x.1 for LAN ip and 10.x.x.0/24 for openvpn subnet.
Substitute numbers between 10 and 250 for the Xs.
-
Not sure. Openvpn is actually really really simple to set up and make work, so if its not working, usually its a simple mistake. The sort of thing that makes you do a giant self-face-palm when you figure it out.
So yeah - If its not that, its something else that simple.
But, we have all been there at one time or another ;D -
Can you do me a favor. Can you go to your main screen that shows your WAN and LAN ip and status. Post that here. please.
-
Currently the zyxel is configured with a static IP. If I put the zyxel into bridge mode, what changes do I need to make on the pfsense WAN port?
You put what's on Zyxel to WAN configuration on pfsense and assign some LAN IP to the Zyxel box.
-
If I put the IP config on the pfsense wan interface and turn the zyxel into a transparent bridge, how will I access the zyxel? @doktornotor:
Currently the zyxel is configured with a static IP. If I put the zyxel into bridge mode, what changes do I need to make on the pfsense WAN port?
You put what's on Zyxel to WAN configuration on pfsense and assign some LAN IP to the Zyxel box.
-
If I put the IP config on the pfsense wan interface and turn the zyxel into a transparent bridge, how will I access the zyxel?
http://doc.pfsense.org/index.php/Accessing_modem_from_inside_firewall - or connect it directly to a PC temporarily… Since there's nothing to configure once done, cannot see how's this exactly an issue.