Setup OpenVPN in 2.0 RC1
-
Hi,
I am having problem connecting to OpenVPN after the updates from 1.2.3 Release to 2.0 RC1, The API of 2.0 RC1 is way different from 1.2.3 Release. I got the following error:
[ovpn_1] Peer Connection Initiated with [AF_INET]:56108
Mar 9 13:32:23 openvpn[12136]: Attempting to establish TCP connection with [AF_INET]:1194 [nonblock]
Mar 9 13:32:23 openvpn[12136]: LZO compression initialized
Mar 9 13:32:23 openvpn[12136]: Re-using SSL/TLS context
Mar 9 13:32:23 openvpn[45933]: WARNING: 'ifconfig' is present in local config but missing in remote config, local='ifconfig 172.16.4.1 172.16.4.2'I did add ifconfig on the client openvpn config file and still getting this message log. The openvpn client is connected but I was unable to access any server or computer in our office LAN.
-
Okay.., I was able to narrow down the problem what I did is I setup the OpenVPN as Remote Access this is basically my setup previously, so I was able to connect without any error but still cannot access the office LAN.
Any suggestion would be greatly appreciated.
Thanks.
-
Did you add firewall rules for the OpenVPN interface? (Firewall > Rules, OpenVPN tab)
On 1.2.3, OpenVPN traffic wasn't filtered.
This is really a remote access setup or is it a site-to-site tunnel?
-
Thank you for the reply, it is just remote access setup, yes I added rule to my OpenVPN rule tab. Still I was able to connect but can't access Office LAN network.
Attached is my configuration see if this is correct setup.
-
By the way aside from adding rule on my OpeVPN tab I also added rule on my WAN the same as what its on my OpenVPN tab rule.
-
@gbtech:
By the way aside from adding rule on my OpeVPN tab I also added rule on my WAN the same as what its on my OpenVPN tab rule.
That's your problem.
On the OpenVPN interface itself you want to allow all protocols to all ports across the tunnel, or at least a different rule than what you have there.
What you show would only allow tcp/udp connects on 1194 to happen over the tunnel itself. This is not really what you want. That is the right rule for the WAN though, just not for the OpenVPN tab.
-
Thank Jimp, I did changed the rules in the OpenVPN tab but still no luck can't access office LAN networks.
Please see attached rules I have for OpenVPN tab.
Thanks.
-
Can you confirm on the client if you have a route to the LAN subnet?
Do a packet capture on the OpenVPN interface to see if the traffic is actually coming in over the vpn interface.
-
Attached herewith is my OpenVPN and wan captured data and also below is my client openvpn log:
Wed Mar 09 15:02:13 2011 OpenVPN 2.1_rc20 i686-pc-mingw32 [SSL] [LZO2] [PKCS11] built on Oct 1 2009
Wed Mar 09 15:02:13 2011 NOTE: OpenVPN 2.1 requires '–script-security 2' or higher to call user-defined scripts or executables
Wed Mar 09 15:02:13 2011 LZO compression initialized
Wed Mar 09 15:02:13 2011 Control Channel MTU parms [ L:1544 D:140 EF:40 EB:0 ET:0 EL:0 ]
Wed Mar 09 15:02:13 2011 Data Channel MTU parms [ L:1544 D:1450 EF:44 EB:135 ET:0 EL:0 AF:3/1 ]
Wed Mar 09 15:02:13 2011 Local Options hash (VER=V4): '69109d17'
Wed Mar 09 15:02:13 2011 Expected Remote Options hash (VER=V4): 'c0103fa8'
Wed Mar 09 15:02:13 2011 Attempting to establish TCP connection with (remote IP):1194
Wed Mar 09 15:02:13 2011 TCP connection established with (remote IP):1194
Wed Mar 09 15:02:13 2011 Socket Buffers: R=[8192->8192] S=[8192->8192]
Wed Mar 09 15:02:13 2011 TCPv4_CLIENT link local: [undef]
Wed Mar 09 15:02:13 2011 TCPv4_CLIENT link remote: (remote IP):1194
Wed Mar 09 15:02:13 2011 TLS: Initial packet from (remote IP):1194, sid=b975df58 f2805c02
Wed Mar 09 15:02:14 2011 VERIFY OK: depth=1, /C=
Wed Mar 09 15:02:14 2011 VERIFY OK: nsCertType=SERVER
Wed Mar 09 15:02:14 2011 VERIFY OK: depth=0, /C=
Wed Mar 09 15:02:16 2011 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Wed Mar 09 15:02:16 2011 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Mar 09 15:02:16 2011 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Wed Mar 09 15:02:16 2011 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Mar 09 15:02:16 2011 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Wed Mar 09 15:02:16 2011 [server] Peer Connection Initiated with (remote IP):1194
Wed Mar 09 15:02:18 2011 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Wed Mar 09 15:02:19 2011 PUSH: Received control message: 'PUSH_REPLY,route 10.0.0.0 255.255.255.0,dhcp-option DOMAIN dc.domain.com,dhcp-option DNS 10.0.0.20,route 172.16.4.1,topology net30,ping 10,ping-restart 60,ifconfig 172.16.4.6 172.16.4.5'
Wed Mar 09 15:02:19 2011 OPTIONS IMPORT: timers and/or timeouts modified
Wed Mar 09 15:02:19 2011 OPTIONS IMPORT: –ifconfig/up options modified
Wed Mar 09 15:02:19 2011 OPTIONS IMPORT: route options modified
Wed Mar 09 15:02:19 2011 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Wed Mar 09 15:02:19 2011 ROUTE default_gateway=192.168.100.50
Wed Mar 09 15:02:19 2011 TAP-WIN32 device [tap0] opened: \.\Global{8934AB08-3872-4547-AD8A-2483524BE7A0}.tap
Wed Mar 09 15:02:19 2011 TAP-Win32 Driver Version 9.6
Wed Mar 09 15:02:19 2011 TAP-Win32 MTU=1500
Wed Mar 09 15:02:19 2011 Notified TAP-Win32 driver to set a DHCP IP/netmask of 172.16.4.6/255.255.255.252 on interface {8934AB08-3872-4547-AD8A-2483524BE7A0} [DHCP-serv: 172.16.4.5, lease-time: 31536000]
Wed Mar 09 15:02:19 2011 Successful ARP Flush on interface [14] {8934AB08-3872-4547-AD8A-2483524BE7A0}
Wed Mar 09 15:02:24 2011 TEST ROUTES: 2/2 succeeded len=2 ret=1 a=0 u/d=up
Wed Mar 09 15:02:24 2011 C:\WINDOWS\system32\route.exe ADD 10.0.0.0 MASK 255.255.255.0 172.16.4.5
Wed Mar 09 15:02:24 2011 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4
Wed Mar 09 15:02:24 2011 Route addition via IPAPI succeeded [adaptive]
Wed Mar 09 15:02:24 2011 C:\WINDOWS\system32\route.exe ADD 172.16.4.1 MASK 255.255.255.255 172.16.4.5
Wed Mar 09 15:02:24 2011 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4
Wed Mar 09 15:02:24 2011 Route addition via IPAPI succeeded [adaptive]
Wed Mar 09 15:02:24 2011 Initialization Sequence Completed
-
Openvpn packet captured
-
wan packet captured.
-
So the data is coming in over the tunnel, going to 10.0.0.20, and never coming back.
Look on LAN to see if that connection leaves LAN going to 10.0.0.20. If you see it go out and not return, then it's a setting on 10.0.0.20 that may be to blame.
-
I am not sure what you trying to say, you mean do a packet captured of LAN and then check to see if it is coming back and if not do I have to check settings on Firewall rule under LAN or do I have to put gateway on my DNS list under "General" option? I setup two DNS one is the DNS of our Internet Provider and one is the local DNS which is 10.0.0.20 that there is no gateway define.
-
I didn't say anything about DNS. Just do a packet capture on LAN, see if you see the same traffic as you did on the OpenVPN interface, going to 10.0.0.20.
If the traffic leaves the LAN interface but doesn't come back, then 10.0.0.20 is dropping the traffic or not routing it back properly.
-
I see in the LAN packet captured that there is coming in from the remote client but nothing coming out.
12:08:34.099736 IP 172.16.4.6.55581 > 10.0.0.20.53: UDP, length 56
12:08:35.099170 IP 172.16.4.6.55581 > 10.0.0.20.53: UDP, length 56
12:08:37.101038 IP 172.16.4.6.55581 > 10.0.0.20.53: UDP, length 56I don't see anything that from 10.0.0.20.53 > 172.16.4.6
-
Then something on 10.0.0.20 isn't responding. It could be any number of things:
- 10.0.0.20 doesn't use the pfSense box as its gateway
- 10.0.0.20 is dropping the traffic (local firewall?)
- 10.0.0.20 isn't configured to allow resolving DNS for 127.16.4.6 so the query is dropped
- 10.0.0.20 is sending the traffic back by some other path (check its routing table)
etc, etc, etc.
