RESOLVED: Please help, such an odd routing problem



  • I've got a site to site OpenVPN link between my two offices.  Site A (Server) can ping any PC in site B (Client).  On site B, I can ping any machine on site A with one exception.  From one specific computer on site B, I can ping NOTHING on site A.  Not even the router.  Every ping times out.  Which is really weird since I can ping the machine from A.

    Site A subnet: 192.168.0.0
    Site B subnet: 192.168.10.0
    Problem machine on subnet B: 192.168.10.2

    Obviously within sites, I can ping anything from anything since it never even touches the router.  I have no idea what could be the problem here in what seems like such a simple setup.  OS concerned in Windows Server 2003.  Firewall is off.  Default gateway is showing up as the router like it should when doing ipconfig /all.



  • what about traceroutes to and from the suspect machine? if you run tcpdump on the remote router adjacent to site b do you see the icmp traffic?



  • Have you tried starting with a Linux-live-cd (like knoppix) to see if you have the same problem?
    This really sounds like a config issue of the problem-computer.



  • @GruensFroeschli:

    Have you tried starting with a Linux-live-cd (like knoppix) to see if you have the same problem?
    This really sounds like a config issue of the problem-computer.

    This is a good idea, only site B is 600 miles away and there isn't a good way to do that.



  • @phospher:

    what about traceroutes to and from the suspect machine? if you run tcpdump on the remote router adjacent to site b do you see the icmp traffic?

    tracert to the suspect computer works fine, goes straight to the router on site A to the computer in question in two hops.  A tracert from the computer in question back to my workstation get to the router on side B and the second hop and all after that just time out.  I'll try a tcpdump next.



  • Update:

    tcpdump shows packets being sent FROM suspect computer on site B.  No replies.  From a good computer on site B, tcpdump shows both packets sent and received.

    FROM suspect PC on site B TO workstation on site A

    listening on fxp0, link-type EN10MB (Ethernet), capture size 96 bytes
    11:02:00.744498 IP 192.168.10.2 > 192.168.0.45: ICMP echo request, id 512, seq 21256, length 40
    11:02:06.170690 IP 192.168.10.2 > 192.168.0.45: ICMP echo request, id 512, seq 21512, length 40
    11:02:11.670552 IP 192.168.10.2 > 192.168.0.45: ICMP echo request, id 512, seq 21768, length 40
    11:02:17.170557 IP 192.168.10.2 > 192.168.0.45: ICMP echo request, id 512, seq 22024, length 40
    

    FROM a good PC on site B TO workstation on site A

    listening on fxp0, link-type EN10MB (Ethernet), capture size 96 bytes
    11:05:41.675919 IP 192.168.10.3 > 192.168.0.45: ICMP echo request, id 512, seq 52480, length 40
    11:05:41.856486 IP 192.168.0.45 > 192.168.10.3: ICMP echo reply, id 512, seq 52480, length 40
    11:05:42.670126 IP 192.168.10.3 > 192.168.0.45: ICMP echo request, id 512, seq 52736, length 40
    11:05:42.945913 IP 192.168.0.45 > 192.168.10.3: ICMP echo reply, id 512, seq 52736, length 40
    11:05:43.670091 IP 192.168.10.3 > 192.168.0.45: ICMP echo request, id 512, seq 52992, length 40
    11:05:43.940606 IP 192.168.0.45 > 192.168.10.3: ICMP echo reply, id 512, seq 52992, length 40
    11:05:44.670057 IP 192.168.10.3 > 192.168.0.45: ICMP echo request, id 512, seq 53248, length 40
    11:05:44.934410 IP 192.168.0.45 > 192.168.10.3: ICMP echo reply, id 512, seq 53248, length 40
    ```Now here's where it starts to get weird. 
    
    TO suspect PC on site B FROM workstation on site A
    

    listening on fxp0, link-type EN10MB (Ethernet), capture size 96 bytes

    
    Notice there's nothing there?  Which is REALLY odd since the workstation got replies from 192.168.10.2 according to it. 
    
    TO good PC on site B FROM workstation on site A
    

    listening on fxp0, link-type EN10MB (Ethernet), capture size 96 bytes
    11:16:04.925069 IP 192.168.0.45 > 192.168.10.3: ICMP echo request, id 768, seq 34048, length 40
    11:16:04.925191 IP 192.168.10.3 > 192.168.0.45: ICMP echo reply, id 768, seq 34048, length 40
    11:16:05.930602 IP 192.168.0.45 > 192.168.10.3: ICMP echo request, id 768, seq 34304, length 40
    11:16:05.930719 IP 192.168.10.3 > 192.168.0.45: ICMP echo reply, id 768, seq 34304, length 40
    11:16:06.760189 IP 192.168.0.45 > 192.168.10.3: ICMP echo request, id 768, seq 34560, length 40
    11:16:06.760299 IP 192.168.10.3 > 192.168.0.45: ICMP echo reply, id 768, seq 34560, length 40
    11:16:07.724386 IP 192.168.0.45 > 192.168.10.3: ICMP echo request, id 768, seq 34816, length 40
    11:16:07.724504 IP 192.168.10.3 > 192.168.0.45: ICMP echo reply, id 768, seq 34816, length 40

    
    Is it possible that someone on site B has a machine or something statically set to 192.168.10.2?  My DHCP scope is set to hand out IP's from 192.168.10.100-150 and the servers are the only thing that are set statically.


  • Have you compared the subnet mask and default gateway on the good and suspect PCs on site B?



  • Update #2:  I got to thinking about the whole "rogue device" thing.  So I opened a browser and typed in 192.168.10.2.  Know what I got?  The site B router's home page.  How in the world did that IP get bound to my router?  This only happens when I browse to the site from site A.  On site B, I get nothing (no web service is installed on that server) which tells me it is a routing problem.



  • Hello,

    I would check first subnet length/default gateway/routing table and assign addresses statically while shooting.

    Can you ping 192.168.10.2 and 192.168.10.3 each other and what those arps look like by the way?

    cheers,



  • @nocer:

    Hello,

    I would check first subnet length/default gateway/routing table and assign addresses statically while shooting.

    Can you ping 192.168.10.2 and 192.168.10.3 each other and what those arps look like by the way?

    cheers,

    On which router should I check all these things?  192.168.10.2 and 192.168.10.3 can both ping each other just fine.  On site B, I did find this oddity in the routing table:

    192.168.10.1 	192.168.10.2 	UH 	1 	0 	1500 	tun0 	 
    

    I have no idea how it got there.  I never assigned 192.168.10.2 to anything.  And the TUN adapter tells me it has something to do with OpenVPN.  Site A is the server and B is the client for a site to site connecting using OpenVPN.



  • OK.  One more edit.  I'm getting close, but don't know how to fix this.

    
    Sep 27 09:49:14 	openvpn[378]: WARNING: file '/var/etc/openvpn_client0.secret' is group or others accessible
    Sep 27 09:49:14 	openvpn[378]: LZO compression initialized
    Sep 27 09:49:14 	openvpn[378]: gw 192.168.100.1
    Sep 27 09:49:14 	openvpn[378]: TUN/TAP device /dev/tun0 opened
    Sep 27 09:49:14 	openvpn[378]: /sbin/ifconfig tun0 192.168.10.2 192.168.10.1 mtu 1500 netmask 255.255.255.255 up
    Sep 27 09:49:14 	openvpn[378]: /etc/rc.filter_configure tun0 1500 1563 192.168.10.2 192.168.10.1 init
    Sep 27 09:49:15 	openvpn[378]: Attempting to establish TCP connection with [SITE A PUBLIC IP]:1194
    Sep 27 09:50:07 	openvpn[378]: /etc/rc.filter_configure tun0 1500 1563 192.168.10.2 192.168.10.1 init
    Sep 27 09:50:08 	openvpn[378]: SIGHUP[hard,init_instance] received, process restarting
    Sep 27 09:50:08 	openvpn[378]: OpenVPN 2.0.6 i386-portbld-freebsd6.2 [SSL] [LZO] built on Sep 13 2007
    Sep 27 09:50:13 	openvpn[378]: WARNING: file '/var/etc/openvpn_client0.secret' is group or others accessible
    Sep 27 09:50:13 	openvpn[378]: LZO compression initialized
    Sep 27 09:50:13 	openvpn[378]: gw [SITE A PUBLIC IP]
    Sep 27 09:50:13 	openvpn[378]: TUN/TAP device /dev/tun0 opened
    Sep 27 09:50:13 	openvpn[378]: /sbin/ifconfig tun0 192.168.10.2 192.168.10.1 mtu 1500 netmask 255.255.255.255 up
    Sep 27 09:50:13 	openvpn[378]: /etc/rc.filter_configure tun0 1500 1563 192.168.10.2 192.168.10.1 init
    Sep 27 09:50:14 	openvpn[378]: Attempting to establish TCP connection with [SITE A PUBLIC IP]:1194
    Sep 27 09:50:14 	openvpn[378]: TCP connection established with [SITE A PUBLIC IP]:1194
    Sep 27 09:50:14 	openvpn[378]: TCPv4_CLIENT link local: [undef]
    Sep 27 09:50:14 	openvpn[378]: TCPv4_CLIENT link remote: [SITE A PUBLIC IP]:1194
    Sep 27 09:50:15 	openvpn[378]: Peer Connection Initiated with [SITE A PUBLIC IP]:1194
    Sep 27 09:50:15 	openvpn[378]: Initialization Sequence Completed
    Sep 27 09:50:24 	openvpn[378]: WARNING: 'ifconfig' is used inconsistently, local='ifconfig 192.168.10.2 192.168.10.1', remote='ifconfig 192.168.6.2 192.168.6.1'
    

    So 192.168.10.2 is somehow getting hijacked by OpenVPN.  Thing is, the openVPN adapter ought be getting an IP in the 192.168.6.0/24 subnet.  I just checked another pfsense router that connects to site A and it shows me the same warning.  I use 192.168.1.0/24 there and OpenVPN is hijacking 192.168.1.2 as well.  Only thing is I don't use that IP in that subnet so it hasn't been a problem.



  • Another post.  I'm uploading images of my setup on both the client and server for VPN.



  • Your interface IP on the client is wrong.
    It should be 192.168.6.0/24



  • Resolved.  Change the "interface IP" to match the IP range specified in the "address pool" in the server config.  Stupid tutorial is WRONG.  When is someone going to fix this?



  • @GruensFroeschli:

    Your interface IP on the client is wrong.
    It should be 192.168.6.0/24

    Yeah, I got that on my own :)  Thanks though.  The last post, your post actually, in this forum post explains the error.



  • Hi

    err….address pool.... :P

    cheers,


Log in to reply