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.9k 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.
    • 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.