Openvpn server not starting (road warrior configuration)

jayw

OpenVPN Server application will not start. I followed the instructions for road warrior config here: http://www.youtube.com/watch?v=02vlrVNbe70

I rebooted pfsense just to make sure and it's abending at startup with the following message:

Jul 25 17:39:36	BLM-Firewall openvpn[21067]: TUN/TAP device /dev/tun1 opened
Jul 25 17:39:36	BLM-Firewall openvpn[21067]: /sbin/ifconfig ovpns1 192.168.0.1 192.168.0.2 mtu 1500 netmask 255.255.255.255 up
Jul 25 17:39:36	BLM-Firewall openvpn[21067]: FreeBSD ifconfig failed: external program exited with error status: 1
Jul 25 17:39:36	BLM-Firewall openvpn[21067]: Exiting

Attached are a network diagram, screen-shots and logfiles from pfsense and OpenVPN.

Any advice would be greatly appreciated.

-jay

OpenVPN Log:

ast 50 OpenVPN log entries
Jul 25 17:06:09	BLM-Firewall openvpn[18571]: TCP: connect to 192.168.1.1:1194 failed, will try again in 5 seconds: Operation timed out
Jul 25 17:06:24	BLM-Firewall openvpn[18571]: TCP: connect to 192.168.1.1:1194 failed, will try again in 5 seconds: Operation timed out
Jul 25 17:06:35	BLM-Firewall openvpn[18571]: SIGTERM[hard,init_instance] received, process exiting
Jul 25 17:17:21	BLM-Firewall openvpn[43917]: OpenVPN 2.2.2 i386-portbld-freebsd8.1 [SSL] [LZO2] [eurephia] built on Apr 2 2013
Jul 25 17:17:21	BLM-Firewall openvpn[43917]: 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 25 17:17:21	BLM-Firewall openvpn[43917]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jul 25 17:17:21	BLM-Firewall openvpn[43917]: Control Channel Authentication: using '/var/etc/openvpn/server1.tls-auth' as a OpenVPN static key file
Jul 25 17:17:21	BLM-Firewall openvpn[43917]: 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)
Jul 25 17:17:21	BLM-Firewall openvpn[43917]: WARNING: potential TUN/TAP adapter subnet conflict between local LAN [192.168.0.0/255.255.255.0] and remote VPN [192.168.0.1/255.255.255.255]
Jul 25 17:17:21	BLM-Firewall openvpn[43917]: TUN/TAP device /dev/tun1 opened
Jul 25 17:17:21	BLM-Firewall openvpn[43917]: /sbin/ifconfig ovpns1 192.168.0.1 192.168.0.2 mtu 1500 netmask 255.255.255.255 up
Jul 25 17:17:21	BLM-Firewall openvpn[43917]: FreeBSD ifconfig failed: external program exited with error status: 1
Jul 25 17:17:21	BLM-Firewall openvpn[43917]: Exiting
Jul 25 17:39:36	BLM-Firewall openvpn[21067]: OpenVPN 2.2.2 i386-portbld-freebsd8.1 [SSL] [LZO2] [eurephia] built on Apr 2 2013
Jul 25 17:39:36	BLM-Firewall openvpn[21067]: 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 25 17:39:36	BLM-Firewall openvpn[21067]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jul 25 17:39:36	BLM-Firewall openvpn[21067]: Control Channel Authentication: using '/var/etc/openvpn/server1.tls-auth' as a OpenVPN static key file
Jul 25 17:39:36	BLM-Firewall openvpn[21067]: 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)
Jul 25 17:39:36	BLM-Firewall openvpn[21067]: WARNING: potential TUN/TAP adapter subnet conflict between local LAN [192.168.0.0/255.255.255.0] and remote VPN [192.168.0.1/255.255.255.255]
Jul 25 17:39:36	BLM-Firewall openvpn[21067]: TUN/TAP device /dev/tun1 opened
Jul 25 17:39:36	BLM-Firewall openvpn[21067]: /sbin/ifconfig ovpns1 192.168.0.1 192.168.0.2 mtu 1500 netmask 255.255.255.255 up
Jul 25 17:39:36	BLM-Firewall openvpn[21067]: FreeBSD ifconfig failed: external program exited with error status: 1
Jul 25 17:39:36	BLM-Firewall openvpn[21067]: Exiting
Jul 25 17:47:51	openvpn[43877]: OpenVPN 2.2.2 i386-portbld-freebsd8.1 [SSL] [LZO2] [eurephia] built on Apr 2 2013
Jul 25 17:47:51	openvpn[43877]: 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 25 17:47:51	openvpn[43877]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jul 25 17:47:52	openvpn[43877]: Control Channel Authentication: using '/var/etc/openvpn/server1.tls-auth' as a OpenVPN static key file
Jul 25 17:47:52	openvpn[43877]: 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)
Jul 25 17:47:52	openvpn[43877]: WARNING: potential TUN/TAP adapter subnet conflict between local LAN [192.168.0.0/255.255.255.0] and remote VPN [192.168.0.1/255.255.255.255]
Jul 25 17:47:52	openvpn[43877]: TUN/TAP device /dev/tun1 opened
Jul 25 17:47:52	openvpn[43877]: /sbin/ifconfig ovpns1 192.168.0.1 192.168.0.2 mtu 1500 netmask 255.255.255.255 up
Jul 25 17:47:52	openvpn[43877]: FreeBSD ifconfig failed: external program exited with error status: 1
Jul 25 17:47:52	openvpn[43877]: Exiting
Jul 25 17:56:20	openvpn[12776]: Control Channel Authentication: using '/var/etc/openvpn/server1.tls-auth' as a OpenVPN static key file
Jul 25 17:56:20	openvpn[12776]: 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)
Jul 25 17:56:20	openvpn[12776]: WARNING: potential TUN/TAP adapter subnet conflict between local LAN [192.168.0.0/255.255.255.0] and remote VPN [192.168.0.1/255.255.255.255]
Jul 25 17:56:20	openvpn[12776]: TUN/TAP device /dev/tun1 opened
Jul 25 17:56:20	openvpn[12776]: /sbin/ifconfig ovpns1 192.168.0.1 192.168.0.2 mtu 1500 netmask 255.255.255.255 up
Jul 25 17:56:20	openvpn[12776]: FreeBSD ifconfig failed: external program exited with error status: 1
Jul 25 17:56:20	openvpn[12776]: Exiting
Jul 25 17:57:32	openvpn[42594]: OpenVPN 2.2.2 i386-portbld-freebsd8.1 [SSL] [LZO2] [eurephia] built on Apr 2 2013
Jul 25 17:57:32	openvpn[42594]: 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 25 17:57:32	openvpn[42594]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jul 25 17:57:32	openvpn[42594]: Control Channel Authentication: using '/var/etc/openvpn/server1.tls-auth' as a OpenVPN static key file
Jul 25 17:57:32	openvpn[42594]: 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)
Jul 25 17:57:32	openvpn[42594]: WARNING: potential TUN/TAP adapter subnet conflict between local LAN [192.168.0.0/255.255.255.0] and remote VPN [192.168.0.1/255.255.255.255]
Jul 25 17:57:32	openvpn[42594]: TUN/TAP device /dev/tun1 opened
Jul 25 17:57:32	openvpn[42594]: /sbin/ifconfig ovpns1 192.168.0.1 192.168.0.2 mtu 1500 netmask 255.255.255.255 up
Jul 25 17:57:32	openvpn[42594]: FreeBSD ifconfig failed: external program exited with error status: 1
Jul 25 17:57:32	openvpn[42594]: Exiting

pfsense Log:

Jul 25 17:56:22	php: : rc.newwanip: on (IP address: 192.168.0.135) (interface: wan) (real interface: fxp0).
Jul 25 17:56:22	php: : ROUTING: setting default route to 192.168.0.1
Jul 25 17:56:22	apinger: Exiting on signal 15.
Jul 25 17:56:23	check_reload_status: Reloading filter
Jul 25 17:56:23	apinger: Starting Alarm Pinger, apinger(27529)
Jul 25 17:56:23	php: : ROUTING: setting default route to 192.168.0.1
Jul 25 17:56:33	apinger: ALARM: PublicWifiGW(10.0.0.1) *** down ***
Jul 25 17:56:43	check_reload_status: Reloading filter
Jul 25 17:56:45	ntpdate[33420]: adjust time server 206.217.199.65 offset 0.259533 sec
Jul 25 17:56:46	dhcpd: Internet Systems Consortium DHCP Server 4.2.4-P2
Jul 25 17:56:46	dhcpd: Copyright 2004-2012 Internet Systems Consortium.
Jul 25 17:56:46	dhcpd: All rights reserved.
Jul 25 17:56:46	dhcpd: For info, please visit https://www.isc.org/software/dhcp/
Jul 25 17:56:46	check_reload_status: Updating all dyndns
Jul 25 17:56:46	dnsmasq[43707]: started, version 2.65 cachesize 10000
Jul 25 17:56:46	dnsmasq[43707]: compile time options: IPv6 GNU-getopt no-DBus i18n IDN DHCP DHCPv6 no-Lua TFTP no-conntrack
Jul 25 17:56:46	dnsmasq[43707]: reading /etc/resolv.conf
Jul 25 17:56:46	dnsmasq[43707]: using nameserver 67.*.*.*#53
Jul 25 17:56:46	dnsmasq[43707]: using nameserver 67.*.*.*#53
Jul 25 17:56:46	dnsmasq[43707]: using nameserver 67.*.*.*#53
Jul 25 17:56:46	dnsmasq[43707]: using nameserver 192.168.0.1#53
Jul 25 17:56:46	dnsmasq[43707]: ignoring nameserver 127.0.0.1 - local interface
Jul 25 17:56:46	dnsmasq[43707]: ignoring nameserver 127.0.0.1 - local interface
Jul 25 17:56:46	dnsmasq[43707]: read /etc/hosts - 2 addresses
Jul 25 17:56:46	kernel: ipfw2 (+ipv6) initialized, divert loadable, nat loadable, rule-based forwarding enabled, default to accept, logging disabled
Jul 25 17:56:46	kernel: load_dn_sched dn_sched FIFO loaded
Jul 25 17:56:46	kernel: load_dn_sched dn_sched QFQ loaded
Jul 25 17:56:46	kernel: load_dn_sched dn_sched RR loaded
Jul 25 17:56:46	kernel: load_dn_sched dn_sched WF2Q+ loaded
Jul 25 17:56:46	kernel: load_dn_sched dn_sched PRIO loaded
Jul 25 17:56:48	check_reload_status: Restarting ipsec tunnels
Jul 25 17:56:51	php: : Creating rrd update script
Jul 25 17:56:51	php: : Restarting/Starting all packages.
Jul 25 17:56:55	php: : IPSEC: One or more IPsec tunnel endpoints has changed its IP. Refreshing.
Jul 25 17:56:55	login: login on ttyv0 as root
Jul 25 17:56:55	login: login on ttyv1 as root
Jul 25 17:56:55	sshlockout[30707]: sshlockout/webConfigurator v3.0 starting up
Jul 25 17:56:57	check_reload_status: Reloading filter
Jul 25 17:57:23	apinger: Error while feeding rrdtool: Broken pipe
Jul 25 17:57:23	apinger: rrdtool respawning too fast, waiting 300s.
Jul 25 17:57:32	check_reload_status: Reloading filter
Jul 25 17:57:32	kernel: ovpns1: link state changed to UP
Jul 25 17:57:32	kernel: ifa_add_loopback_route: insertion failed
Jul 25 17:57:32	kernel: ovpns1: link state changed to DOWN
Jul 25 17:57:37	lighttpd[29549]: (network_writev.c.112) writev failed: Operation not permitted 10
Jul 25 17:57:37	lighttpd[29549]: (network_writev.c.112) writev failed: Operation not permitted 10
Jul 25 17:57:37	lighttpd[29549]: (connections.c.637) connection closed: write failed on fd 10
Jul 25 17:57:37	lighttpd[29549]: (connections.c.637) connection closed: write failed on fd 10
Jul 25 17:58:18	lighttpd[29549]: (connections.c.137) (warning) close: 10 Connection reset by peer
Jul 25 17:58:18	lighttpd[29549]: (connections.c.137) (warning) close: 10 Connection reset by peer

![Open VPN Server-small2.gif_thumb](/public/imported_attachments/1/Open VPN Server-small2.gif_thumb)
![Open VPN Server-small2.gif](/public/imported_attachments/1/Open VPN Server-small2.gif)
![Network diagram2.gif](/public/imported_attachments/1/Network diagram2.gif)
![Network diagram2.gif_thumb](/public/imported_attachments/1/Network diagram2.gif_thumb)
![openvpn server client-export-small1.gif](/public/imported_attachments/1/openvpn server client-export-small1.gif)
![openvpn server client-export-small1.gif_thumb](/public/imported_attachments/1/openvpn server client-export-small1.gif_thumb)

![openvpn-system-Certificate Manager-small1.gif](/public/imported_attachments/1/openvpn-system-Certificate Manager-small1.gif)
![openvpn-system-Certificate Manager-small1.gif_thumb](/public/imported_attachments/1/openvpn-system-Certificate Manager-small1.gif_thumb)

phil.davis

Jul 25 17:17:21	BLM-Firewall openvpn[43917]: 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 25 17:17:21	BLM-Firewall openvpn[43917]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jul 25 17:17:21	BLM-Firewall openvpn[43917]: Control Channel Authentication: using '/var/etc/openvpn/server1.tls-auth' as a OpenVPN static key file
Jul 25 17:17:21	BLM-Firewall openvpn[43917]: 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)
Jul 25 17:17:21	BLM-Firewall openvpn[43917]: WARNING: potential TUN/TAP adapter subnet conflict between local LAN [192.168.0.0/255.255.255.0] and remote VPN [192.168.0.1/255.255.255.255]

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.

jayw

@phil.davis:

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

phil.davis

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…

jayw

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

phil.davis

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 :)

jayw

I'm struggling with this. Are you saying " turn off the nat & routing functions in the ZyXel?"

@phil.davis:

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 :)

doktornotor

@jayw:

I'm struggling with this. Are you saying " turn off the nat & routing functions in the ZyXel?"

Yes, definitely.

jayw

@doktornotor:

@jayw:

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

phil.davis

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.

phil.davis

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.

doktornotor

@phil.davis:

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.

jayw

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

?

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)

jayw

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)

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.

jayw

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.

kejianshi

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

kejianshi

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.

doktornotor

@jayw:

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.

jayw

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:

@jayw:

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.

doktornotor

@jayw:

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.

jayw

Thanks for the advice!

I have to wait until after hours to make changes but hopefully will get to it tonight.

-j