Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    RESOLVED: Please help, such an odd routing problem

    Scheduled Pinned Locked Moved OpenVPN
    16 Posts 5 Posters 8.7k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • B
      benutne
      last edited by

      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.

      1 Reply Last reply Reply Quote 0
      • P
        phospher
        last edited by

        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?

        1 Reply Last reply Reply Quote 0
        • GruensFroeschliG
          GruensFroeschli
          last edited by

          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.

          We do what we must, because we can.

          Asking questions the smart way: http://www.catb.org/esr/faqs/smart-questions.html

          1 Reply Last reply Reply Quote 0
          • B
            benutne
            last edited by

            @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.

            1 Reply Last reply Reply Quote 0
            • B
              benutne
              last edited by

              @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.

              1 Reply Last reply Reply Quote 0
              • B
                benutne
                last edited by

                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.
                1 Reply Last reply Reply Quote 0
                • Cry HavokC
                  Cry Havok
                  last edited by

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

                  1 Reply Last reply Reply Quote 0
                  • B
                    benutne
                    last edited by

                    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.

                    1 Reply Last reply Reply Quote 0
                    • N
                      nocer
                      last edited by

                      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,

                      1 Reply Last reply Reply Quote 0
                      • B
                        benutne
                        last edited by

                        @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.

                        1 Reply Last reply Reply Quote 0
                        • B
                          benutne
                          last edited by

                          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.

                          1 Reply Last reply Reply Quote 0
                          • B
                            benutne
                            last edited by

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

                            1 Reply Last reply Reply Quote 0
                            • GruensFroeschliG
                              GruensFroeschli
                              last edited by

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

                              We do what we must, because we can.

                              Asking questions the smart way: http://www.catb.org/esr/faqs/smart-questions.html

                              1 Reply Last reply Reply Quote 0
                              • B
                                benutne
                                last edited by

                                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?

                                1 Reply Last reply Reply Quote 0
                                • B
                                  benutne
                                  last edited by

                                  @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.

                                  1 Reply Last reply Reply Quote 0
                                  • N
                                    nocer
                                    last edited by

                                    Hi

                                    err….address pool.... :P

                                    cheers,

                                    1 Reply Last reply Reply Quote 0
                                    • First post
                                      Last post
                                    Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.