[SOLVED] Yet another "Cannont ping internal network" question
-
I'm completely stumped. I've set up my OpenVPN connection for road warriors using PKI exactly like another site which works just fine. Connecting works, I just cannot ping any internal hosts using the VPN.
- Windows 7 x64 Enterprise client
- Server is pfSense 1.2
- My local IP range is 192.168.1.0/24.
- LAN inside VPN is 192.168.10.0/24
- Address pool for VPN clients is 10.0.10.0/24
- WAN rule on firewall is set to allow TCP/UDP from any IP and port to port 1194 on any gateway (error is surely not here since I'm getting connected)
- LAN rule on firewall is set to allow ANY protocol from 10.0.10.0/24 to anything on the default gateway
- Another LAN rule set to allow ANY protocol from ANY source to 10.0.10.0/24 on default gateway
- Client get assigned the IP 10.0.10.10
Here is the client log:
Tue Nov 16 11:29:54 2010 OpenVPN 2.1.4 i686-pc-mingw32 [SSL] [LZO2] [PKCS11] built on Nov 8 2010 Tue Nov 16 11:29:54 2010 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables Tue Nov 16 11:29:54 2010 LZO compression initialized Tue Nov 16 11:29:54 2010 Control Channel MTU parms [ L:1558 D:138 EF:38 EB:0 ET:0 EL:0 ] Tue Nov 16 11:29:54 2010 Socket Buffers: R=[8192->8192] S=[8192->8192] Tue Nov 16 11:29:54 2010 Data Channel MTU parms [ L:1558 D:1450 EF:58 EB:135 ET:0 EL:0 AF:3/1 ] Tue Nov 16 11:29:54 2010 Local Options hash (VER=V4): '22188c5b' Tue Nov 16 11:29:54 2010 Expected Remote Options hash (VER=V4): 'a8f55717' Tue Nov 16 11:29:54 2010 UDPv4 link local: [undef] Tue Nov 16 11:29:54 2010 UDPv4 link remote: PUBLIC IP OF SERVER:1194 Tue Nov 16 11:29:54 2010 TLS: Initial packet from PUBLIC IP OF SERVER:1194, sid=blah blah Tue Nov 16 11:29:55 2010 VERIFY OK: depth=1, /C=US/ST=TX/L=Austin/O=mycompany.com/CN=city-ca/emailAddress=administrator@mycompany.com Tue Nov 16 11:29:55 2010 VERIFY OK: nsCertType=SERVER Tue Nov 16 11:29:55 2010 VERIFY OK: depth=0, /C=US/ST=TX/O=mycompany.com/CN=server/emailAddress=administrator@mycompany.com Tue Nov 16 11:30:03 2010 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key Tue Nov 16 11:30:03 2010 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Tue Nov 16 11:30:03 2010 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key Tue Nov 16 11:30:03 2010 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Tue Nov 16 11:30:03 2010 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA Tue Nov 16 11:30:03 2010 [server] Peer Connection Initiated with PUBLIC IP OF SERVER:1194 Tue Nov 16 11:30:05 2010 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1) Tue Nov 16 11:30:05 2010 PUSH: Received control message: 'PUSH_REPLY,route 192.168.10.0 255.255.255.0,dhcp-option DOMAIN mycompany.com,dhcp-option DNS 192.168.10.2,dhcp-option DNS 192.168.10.3,dhcp-option WINS 192.168.10.2,route 10.0.10.1,ping 10,ping-restart 60,ifconfig 10.0.10.10 10.0.10.9' Tue Nov 16 11:30:05 2010 OPTIONS IMPORT: timers and/or timeouts modified Tue Nov 16 11:30:05 2010 OPTIONS IMPORT: --ifconfig/up options modified Tue Nov 16 11:30:05 2010 OPTIONS IMPORT: route options modified Tue Nov 16 11:30:05 2010 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified Tue Nov 16 11:30:05 2010 ROUTE default_gateway=192.168.1.1 Tue Nov 16 11:30:05 2010 TAP-WIN32 device [Local Area Connection 2] opened: \\.\Global\{90C38FA9-915B-45A2-BC36-84D9A02667A7}.tap Tue Nov 16 11:30:05 2010 TAP-Win32 Driver Version 9.7 Tue Nov 16 11:30:05 2010 TAP-Win32 MTU=1500 Tue Nov 16 11:30:05 2010 Notified TAP-Win32 driver to set a DHCP IP/netmask of 10.0.10.10/255.255.255.252 on interface {90C38FA9-915B-45A2-BC36-84D9A02667A7} [DHCP-serv: 10.0.10.9, lease-time: 31536000] Tue Nov 16 11:30:05 2010 Successful ARP Flush on interface [41] {90C38FA9-915B-45A2-BC36-84D9A02667A7} Tue Nov 16 11:30:10 2010 TEST ROUTES: 2/2 succeeded len=2 ret=1 a=0 u/d=up Tue Nov 16 11:30:10 2010 C:\WINDOWS\system32\route.exe ADD 192.168.10.0 MASK 255.255.255.0 10.0.10.9 Tue Nov 16 11:30:10 2010 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4 Tue Nov 16 11:30:10 2010 Route addition via IPAPI succeeded [adaptive] Tue Nov 16 11:30:10 2010 C:\WINDOWS\system32\route.exe ADD 10.0.10.1 MASK 255.255.255.255 10.0.10.9 Tue Nov 16 11:30:10 2010 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4 Tue Nov 16 11:30:10 2010 Route addition via IPAPI succeeded [adaptive] Tue Nov 16 11:30:10 2010 Initialization Sequence Completed
and here is the Windows routing table:
=========================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.45 25 10.0.10.1 255.255.255.255 10.0.10.9 10.0.10.10 30 10.0.10.8 255.255.255.252 On-link 10.0.10.10 286 10.0.10.10 255.255.255.255 On-link 10.0.10.10 286 10.0.10.11 255.255.255.255 On-link 10.0.10.10 286 127.0.0.0 255.0.0.0 On-link 127.0.0.1 306 127.0.0.1 255.255.255.255 On-link 127.0.0.1 306 127.255.255.255 255.255.255.255 On-link 127.0.0.1 306 192.168.1.0 255.255.255.0 On-link 192.168.1.45 281 192.168.1.45 255.255.255.255 On-link 192.168.1.45 281 192.168.1.255 255.255.255.255 On-link 192.168.1.45 281 192.168.10.0 255.255.255.0 10.0.10.9 10.0.10.10 30 224.0.0.0 240.0.0.0 On-link 127.0.0.1 306 224.0.0.0 240.0.0.0 On-link 192.168.1.45 281 224.0.0.0 240.0.0.0 On-link 10.0.10.10 286 255.255.255.255 255.255.255.255 On-link 127.0.0.1 306 255.255.255.255 255.255.255.255 On-link 192.168.1.45 281 255.255.255.255 255.255.255.255 On-link 10.0.10.10 286 ===========================================================================
No software firewalls (Windows one disabled) no antivirus software. I have an identically configured VPN and firewall (different local IPs and public IPs) that works just fine. I'm so confused as to why this one isn't working. Please help.
-
- You said 1.2, is that really 1.2.3 or 1.2? If it's on 1.2 it should really be upgraded to 1.2.3.
- Is the pfSense router the default gateway for items on 192.168.10.x?
- The first LAN rule is unnecessary. OpenVPN traffic would not hit the LAN with a source IP like that.
- The second LAN rule is OK.
- If you do a packet capture on LAN (Diagnostics > Packet Capture), do you see the traffic coming from the 10.x IPs to LAN and any replies back?
-
I'm pretty sure its just 1.2. I know it need to be upgraded but I get a two week window at the end of every year for service blackouts which is when I do all my infrastructure upgrades. I can't have any scheduled interruptions in service till then. I know the first LAN rule isn't necessary, I was just grasping at straws looking for something that might fix the issue. The pfSense is the only router on the 192.168.10.x network, so yeah, it's the default gateway. Pretty simple setup really. One internet connection, one pfSense box. I haven't done a packet capture yet on the pfSense side yet, but a tracert on the client end never even reached the gateway. First hop times out. I'll try the packet capture as soon as I can get away from the office to try the VPN again.
-
- If you do a packet capture on LAN (Diagnostics > Packet Capture), do you see the traffic coming from the 10.x IPs to LAN and any replies back?
OK, I got it set up at home and remotely logged in, fired up the VPN and did a ping to a host on the inside of the network. Here are the results with the VPN client (10.0.10.10) as the host address:
11:16:26.299317 IP 10.0.10.10 > 192.168.10.2: ICMP echo request, id 1, seq 121, length 40 11:16:26.299434 IP 192.168.10.2 > 10.0.10.10: ICMP echo reply, id 1, seq 121, length 40 11:16:31.109321 IP 10.0.10.10 > 192.168.10.2: ICMP echo request, id 1, seq 122, length 40 11:16:31.109433 IP 192.168.10.2 > 10.0.10.10: ICMP echo reply, id 1, seq 122, length 40 11:16:36.115100 IP 10.0.10.10 > 192.168.10.2: ICMP echo request, id 1, seq 123, length 40 11:16:36.115214 IP 192.168.10.2 > 10.0.10.10: ICMP echo reply, id 1, seq 123, length 40 11:16:41.106907 IP 10.0.10.10 > 192.168.10.2: ICMP echo request, id 1, seq 124, length 40 11:16:41.107116 IP 192.168.10.2 > 10.0.10.10: ICMP echo reply, id 1, seq 124, length 40
And the exact same test with the internal host (192.168.10.2) as the host address:
11:21:43.662254 IP 10.0.10.10 > 192.168.10.2: ICMP echo request, id 1, seq 125, length 40 11:21:43.662363 IP 192.168.10.2 > 10.0.10.10: ICMP echo reply, id 1, seq 125, length 40 11:21:43.662484 IP 192.168.10.1 > 192.168.10.2: ICMP host 10.0.10.10 unreachable, length 36 11:21:48.614426 IP 10.0.10.10 > 192.168.10.2: ICMP echo request, id 1, seq 126, length 40 11:21:48.614536 IP 192.168.10.2 > 10.0.10.10: ICMP echo reply, id 1, seq 126, length 40 11:21:48.614641 IP 192.168.10.1 > 192.168.10.2: ICMP host 10.0.10.10 unreachable, length 36 11:21:53.625517 IP 10.0.10.10 > 192.168.10.2: ICMP echo request, id 1, seq 127, length 40 11:21:53.625625 IP 192.168.10.2 > 10.0.10.10: ICMP echo reply, id 1, seq 127, length 40 11:21:53.625749 IP 192.168.10.1 > 192.168.10.2: ICMP host 10.0.10.10 unreachable, length 36 11:21:58.614212 IP 10.0.10.10 > 192.168.10.2: ICMP echo request, id 1, seq 128, length 40 11:21:58.614320 IP 192.168.10.2 > 10.0.10.10: ICMP echo reply, id 1, seq 128, length 40 11:21:58.614423 IP 192.168.10.1 > 192.168.10.2: ICMP host 10.0.10.10 unreachable, length 36
If I'm reading that right, the local host is getting the pings and sending replies. The VPN client just isn't getting any of those replies. It can't be anything specific to the VPN location, I've tried the same connection at several free WiFi spots and at home as well.
Just in case, here is the client config:
client dev tun proto udp 1194 remote PUBLIC IP 1194 ping 10 resolv-retry infinite nobind persist-key persist-tun ca myca.crt cert mycert.crt key mykey.key ns-cert-type server comp-lzo pull verb 3 cipher AES-256-CBC
If someone tells me how I can get you the server config I'll post that too.
-
ISSUES RESOLVED!
For some reason, there was a static route set to 192.168.0.1 for the 10.0.10.x subnet. I have no idea who set this up, but the route had zero traffic on it. I'm guessing one of the other admins (gone now) who was responsible for this location had made the change and not documented it.
Thanks for the help. I was about to go out of my mind.