• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
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 Oct 3, 2008, 6:45 PM

    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
    • G
      GruensFroeschli
      last edited by Oct 4, 2008, 12:03 AM

      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 Oct 6, 2008, 3:53 PM

        @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 Oct 6, 2008, 3:56 PM

          @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 Oct 6, 2008, 4:25 PM

            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
            • C
              Cry Havok
              last edited by Oct 6, 2008, 4:33 PM

              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 Oct 6, 2008, 6:16 PM Oct 6, 2008, 5:01 PM

                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 Oct 7, 2008, 12:23 AM

                  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 Oct 7, 2008, 1:26 PM

                    @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 Oct 7, 2008, 1:41 PM

                      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 Oct 7, 2008, 2:10 PM

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

                        1 Reply Last reply Reply Quote 0
                        • G
                          GruensFroeschli
                          last edited by Oct 7, 2008, 2:13 PM

                          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 Oct 7, 2008, 2:26 PM

                            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 Oct 7, 2008, 2:28 PM

                              @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 Oct 9, 2008, 8:50 PM

                                Hi

                                err….address pool.... :P

                                cheers,

                                1 Reply Last reply Reply Quote 0
                                16 out of 16
                                • First post
                                  16/16
                                  Last post
                                Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                                  This community forum collects and processes your personal information.
                                  consent.not_received