RESOLVED: Please help, such an odd routing problem
-
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. -
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.
-
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 40Is 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,
-
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?
-
Your interface IP on the client is wrong.
It should be 192.168.6.0/24Yeah, 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,