VPN tunnel problem

Discussion in 'Networks' started by Sparky, Jun 29, 2006.

  1. Sparky
    Highly Decorated Member Award 500 Likes Award

    Sparky Zettabyte Poster Moderator

    10,718
    543
    364
    Ok, I have two DG834G Netgear routers running the latest firmware on two remote sites. I can connect both of them with a VPN tunnel, the status is connected and I can drop and reconnect the tunnel if need be.

    The problem is that no traffic between the two sites flows. From the diagnostics on one router I cannot ping the internal I.P of the router on the other remote site. I assume this has something to do with routing. I have both LANs broadcasting their routing tables but no joy.

    Can anyone give me some pointers? Many virtual beers available! If more info in the network is required I can post more.
     
    Certifications: MSc MCSE MCSA:M MCSA:S MCITP:EA MCTS(x5) MS-900 AZ-900 Security+ Network+ A+
    WIP: Microsoft Certs
  2. Baba O'Riley

    Baba O'Riley Gigabyte Poster

    1,760
    23
    99
    I think this is a function of VPNs.
    For example, when I connect to our company VPN from home, I can no longer ping my router because my router is on my network and the laptop I am connecting with is on my company's network. Can you access any remote resources or ping any remote clients?
     
    Certifications: A+, Network+
    WIP: 70-270
  3. Sparky
    Highly Decorated Member Award 500 Likes Award

    Sparky Zettabyte Poster Moderator

    10,718
    543
    364
    I know what you mean mate. The VPN you are describing is your PC connecting to your works network. The one I am setting up is a point to point VPN configured with the two routers; there is a separate subnet on each site. I have tried pinging other devices on the remote (when I am physically on one site) site but no joy.

    Also if a do a tracert from my laptop to a device on the remote site it doesn’t get pass the router on the site I am at. I assume the request does not know where to go when it hits the router, it cant be resolved by ‘real world’ DNS and it isn’t on the site where I am located so somehow I need to put the request through the tunnel but this is the problem.

    I downloaded all the Netgear .pdfs and followed them and still get the problem
     
    Certifications: MSc MCSE MCSA:M MCSA:S MCITP:EA MCTS(x5) MS-900 AZ-900 Security+ Network+ A+
    WIP: Microsoft Certs
  4. Baba O'Riley

    Baba O'Riley Gigabyte Poster

    1,760
    23
    99
    Firewall?
     
    Certifications: A+, Network+
    WIP: 70-270
  5. nugget
    Honorary Member

    nugget Junior toady

    7,796
    71
    224
    Have you checked your NAT settings?
     
    Certifications: A+ | Network+ | Security+ | MCP (270,271,272,290,620) | MCDST | MCTS:Vista
    WIP: MCSA, 70-622,680,685
  6. Sparky
    Highly Decorated Member Award 500 Likes Award

    Sparky Zettabyte Poster Moderator

    10,718
    543
    364
    I thought this might be part of the problem but supposedly because I have defined the full I.P range on the remote site settings that should put all requests through the tunnel.

    In regard to the firewall I configured all inbound and outbound traffic to pass through as a quick test and still nothing! :blink

    Thanks for your input so far guys 8)
     
    Certifications: MSc MCSE MCSA:M MCSA:S MCITP:EA MCTS(x5) MS-900 AZ-900 Security+ Network+ A+
    WIP: Microsoft Certs
  7. Sparky
    Highly Decorated Member Award 500 Likes Award

    Sparky Zettabyte Poster Moderator

    10,718
    543
    364
    Reading the Netgear support page it says there is no need to define static routes as long as Routing Info Protocol is enabled so the routing groups are broadcasted between routers. This is enabled and I have selected the protocol that supports broadcasting subnets.

    Still confused! :blink
     
    Certifications: MSc MCSE MCSA:M MCSA:S MCITP:EA MCTS(x5) MS-900 AZ-900 Security+ Network+ A+
    WIP: Microsoft Certs
  8. r.h.lee

    r.h.lee Gigabyte Poster

    1,011
    52
    105
    Disclaimer: I'm not a VPN expert.

    Sparky,

    From what I understand of VPN networking of two LANs, it effectively makes both LANs part of a single LAN. With that said, do both LANs share a common subnet mask so that you are able to ping from one side of the consolidated LAN to the other side of the consolidated LAN?

    Let's walk through a bit of a networking thought experiment. Let's say you've got computer1 with IP address 192.168.1.2 255.255.255.0 and computer2 with IP address 10.0.0.2 255.0.0.0 and they're both connected to a Hub. Now, logically, even though they're almost directly connected through a Hub, they won't be able to ping each other.

    Now, if you use a router between computer1 and computer2, since routers connect sub/networks, you should be able to ping each other.

    Now, with VPNs, be it LAN to LAN, LAN to HQ, the VPN endpoint routers basically act like switches because each network on LAN1 is connected to LAN2. That's how a computer at a remote site in a LAN to HQ VPN connection is able to receive a valid IP address from the HQ DHCP server over the VPN connection that applies to the HQ LAN.

    So in summary, try using a common subnet mask in both LANs in order to ping each other.

    I hope this helps.
     
    Certifications: MCSE, MCP+I, MCP, CCNA, A+
    WIP: CCDA
  9. Spice_Weasel

    Spice_Weasel Kilobyte Poster

    254
    45
    45
    Actually, try keeping seperate subnets on the two LANs. It can require additional setup to get routing to work properly on a split network, and I doubt the Netgear has the flexibility (in terms of routing protocols) to properly support same network. You might be able to do it using plenty of static routes but it isn't worth the headache.

    First, ensure that the routers are establishing a vpn connection. I've seen routers show "connected" for a vpn tunnel that were not actually properly passing the vpn traffic.

    Add a static route on each router pointing to the remote LAN. If you are using RIP, check the routing table to see if any updates are being received. With only two networks static routes are fine, no need for RIP, but if you can see RIP updates you should have no problem pinging remote machines.

    I assume there is no problem with browsing the internet, pinging internet hosts, etc.

    Try de-selecting vpn passthrough, and if nat-t is available, try selecting it. If you have access to a packet sniffer on the outbound interface, that would really help.


    Spice_Weasel
     
    Certifications: CCNA, CCNP, CCIP, JNCIA-ER, JNCIS-ER,MCP
    WIP: CCIE
  10. Sparky
    Highly Decorated Member Award 500 Likes Award

    Sparky Zettabyte Poster Moderator

    10,718
    543
    364
    Thanks for the input guys.

    Just to give you an update, I phoned Netgear today as I thought I had exhausted all possibilities on the actual config. One of the engineers used remote management to see the config on both routers and agreed that everything is correct. He suggested downgrading both routers firmware as I was using the latest version of the firmware.

    I downgraded and the problem was still the same. I phoned back and another tech had a look at the config and again agreed everything is ok. He then said they are going to escalate the problem to more experienced engineers.

    Hopefully the problem will get resolved but I feel I might have to rip out both routers and start over with a more robust solution. I looked on the Netgear website and it appears the point to point VPN capability has only recently been added to the router so perhaps some teething problems.

    I think its best to have a different subnet on each site, that’s the way I have always configured this type of network before. I have enabled RIP and also put in static routes but the routing tables do not update in either router with both subnets.

    Time for a beer I think! :biggrin

    Edit: Internet browsing is fine, tried with NAT on and off and can ping external hosts.
     
    Certifications: MSc MCSE MCSA:M MCSA:S MCITP:EA MCTS(x5) MS-900 AZ-900 Security+ Network+ A+
    WIP: Microsoft Certs
  11. r.h.lee

    r.h.lee Gigabyte Poster

    1,011
    52
    105
    Sparky,

    Do you realize that by having different subnets on either sides of the VPN pipe is just like connecting computer1 (IP 192.168.1.2 255.255.255.0) and computer2 (IP 10.0.0.2 255.0.0.0) to a hub and wondering why you can't ping from computer1 to computer2 and vice versa? Even if computer1 was connected to computer2 using a crossover cable, they still wouldn't be able to ping each other. This situation would be true even if computer1 (IP 192.168.1.2 255.255.255.0) and computer2 (IP 192.168.2.2 255.255.255.0) because even though the subnet masks are the same, they are on different subnetworks, therefore non-pingable. You'd need a router to route between the 192.168.1.0 subnetwork and the 192.168.2.0 subnetwork.

    Would it be prohibited to experiment changing the IP scheme of one side to the other due to business interruption potential?
     
    Certifications: MCSE, MCP+I, MCP, CCNA, A+
    WIP: CCDA
  12. Spice_Weasel

    Spice_Weasel Kilobyte Poster

    254
    45
    45
    Actually, the networks on each side of the VPN *must* be different, unless either:

    - The vpn is a bridge, which would be very rare, and likely not work well, as broadcast traffic, latency, etc. become a big problem. Besides, I doubt the netgear routers support a bridged VPN connection.

    - The routers are very flexible (which I doubt) and can be set up to accomodate a split network, which can be a lot of work to implement.

    For example, imagine both sides use the 192.168.1.0/24 network. If a computer on side A (ip 192.168.1.10) wants to ping a computer on side B (ip 192.168.1.170), watch what will happen. The comp will send out an arp request for 192.168.1.10, because the computer will assume that 192.168.1.10 is in the same broadcast domain, because they have the same network.

    The router will not pass the arp request to network B because it is a L2 broadcast. So the comp will never receive a reply and won't know the mac address to send the ping to, and the ping will fail.

    But if the networks are different (e.g., side A is now 10.10.10.0/24) then the computer will not send an arp request because it knows the destination computer is on another network. It will send the ping to its default gateway, the router. The router will check its routing tables, see that it has a route to the 192.168.1.0/24 network via the other netgear across the Internet. So it will send the packet to the other router, which will put the packet onto the internal lan, where it will reach the 192.168.1.10 computer.

    So they need to be different networks, unless the routers are acting a bridge, or there is some very dodgy manipulation of routing tables on both sides, which is not a good idea.

    Actually, you could keep both networks by double NAT'ing, but again I don't think the netgear would support that.

    Hope that helps a bit! If you want to roll up your sleeves and try troubleshooting it I can offer some suggestions, but it depends on if it is worth the effort. If you are going to change equipment, or if netgear will be solving it one way or another, it might not be worth spending a lot of time on troubleshooting.


    Spice_Weasel
     
    Certifications: CCNA, CCNP, CCIP, JNCIA-ER, JNCIS-ER,MCP
    WIP: CCIE
  13. Sparky
    Highly Decorated Member Award 500 Likes Award

    Sparky Zettabyte Poster Moderator

    10,718
    543
    364
    This is how I thought the setup would work to be honest. I have worked with network topologies like this before and that’s how it has been setup, the only difference this time is that I’m using Netgear products. :blink

    As for not being able to ping the other subnet either way this confuses me. The device is a router\firewall\switch so surely it has the capability to support the two class C subnets one on each site? I might change one site to be on the same subnetwork as a test.

    It’s in Netgears hands just now and I will be chasing the call on Monday. I`ll let you know what happens either way.

    Cheers guys 8)
     
    Certifications: MSc MCSE MCSA:M MCSA:S MCITP:EA MCTS(x5) MS-900 AZ-900 Security+ Network+ A+
    WIP: Microsoft Certs
  14. Sparky
    Highly Decorated Member Award 500 Likes Award

    Sparky Zettabyte Poster Moderator

    10,718
    543
    364
    Update:

    So I learn something new every day....
    (1) The Netgear diagnostics are rubbish
    (2) The second line support Netgear chaps are very helpful

    Just to expand on my first point, when I was testing the VPN tunnel I was connected to both routers via remote management and using the Netgear diagnostic tools to ping the internal I.P of the router on the remote site. Guess what? The Netgear diagnostic tools don’t support this feature. I phoned the IT administrator who was on-site and asked him to ping the I.P of the router on the remote site and it worked (he opened a good old fashioned command line on his PC), arrgh!

    A step in the right direction, so I phone the guys on the remote site and ask if they can ping the router at the main site (still with me?), nothing happens! Also going back to the original site I cant ping anything else on the remote site and with a tracert the packets don’t leave the LAN but it does when I use the I.P of the external router.

    Confused? I am! The guys at Netgear say they are to and they are going to get someone from the UK support team to phone me back as I was dealing with the guys in the US today (very helpful by the way).

    Any thoughts? I’m thinking there must be a problem in the routing tables. :blink
     
    Certifications: MSc MCSE MCSA:M MCSA:S MCITP:EA MCTS(x5) MS-900 AZ-900 Security+ Network+ A+
    WIP: Microsoft Certs
  15. r.h.lee

    r.h.lee Gigabyte Poster

    1,011
    52
    105
    Sparky,

    So here's what I understand of the situation:

    1. Main Site
      1. You are located at the Main Site
      2. IP Scheme 1
      3. Networking device: Netgear DG834G
    2. Remote Site
      1. There is an IT administrator at the Remote Site
      2. IP Scheme 2
      3. Networking device: Netgear DG834G

    So far so good?
     
    Certifications: MCSE, MCP+I, MCP, CCNA, A+
    WIP: CCDA
  16. Sparky
    Highly Decorated Member Award 500 Likes Award

    Sparky Zettabyte Poster Moderator

    10,718
    543
    364
    Correct,no word from Netgear today as well, will chase them tomorrow :biggrin
     
    Certifications: MSc MCSE MCSA:M MCSA:S MCITP:EA MCTS(x5) MS-900 AZ-900 Security+ Network+ A+
    WIP: Microsoft Certs
  17. Spice_Weasel

    Spice_Weasel Kilobyte Poster

    254
    45
    45
    So, to recap:

    - Users in both sites have no problems accessing the Internet.
    - Users can ping the external interface of the other sites Netgear router.
    - The vpn tunnel is up, according to the information from the routers, but no traffic passes to the other network

    Sparky, you mentioned that a tracert to the other network fails and the packets do not leave the LAN. Is there any way to be sure of this? I assume that in the output from the tracert the first hop is the local router's LAN interface. Are there any hops displayed after that?

    The ping packets could be leaving your LAN, because you would not usually see any hops from a tracert (except your router LAN interface) with the setup you describe with the vpn not working. It could be useful to find out for certain if the ping packets are leaving the LAN as that will help point out where the vpn is failing.

    Spice_Weasel
     
    Certifications: CCNA, CCNP, CCIP, JNCIA-ER, JNCIS-ER,MCP
    WIP: CCIE
  18. Sparky
    Highly Decorated Member Award 500 Likes Award

    Sparky Zettabyte Poster Moderator

    10,718
    543
    364
    - Users in both sites have no problems accessing the Internet.
    *Yup, no problems

    - Users can ping the external interface of the other sites Netgear router.
    *Users can ping the WAN port on each router regardless of which site they are on

    - The vpn tunnel is up, according to the information from the routers, but no traffic passes to the other network
    *On site A the users can ping the LAN I.P of the Router on site B however if they ping anything else on site B it times out. When doing the same tests except with tracert it works to the router on site B (two hops which is both routers) however the tracert fails if I put a PCs I.P address in. The tracert fails on the first hop on the first router. I would have expected it to hop over both routers as this has worked previously when just using the router on the remote sites I.P address.
     
    Certifications: MSc MCSE MCSA:M MCSA:S MCITP:EA MCTS(x5) MS-900 AZ-900 Security+ Network+ A+
    WIP: Microsoft Certs
  19. Spice_Weasel

    Spice_Weasel Kilobyte Poster

    254
    45
    45
    Ah, thanks. I thought that site A couldn't ping anything at site B. But they can ping the site B router's LAN interface, but not any host on the LAN.

    I assume the setup looks something like this:

    Site A
    Network 192.168.1.0/24
    Site A router LAN ip 192.168.1.1
    Site A host ip 192.168.1.20

    Site B
    Network 192.168.5.0/24
    Site B router LAN ip 192.168.5.1
    Site B host ip 192.168.5.20

    The site A comp at 192.168.1.20 can ping 192.168.5.1, but cannot ping 192.168.5.20

    Tracert to 192.168.5.1 has responses from 192.168.1.1 and 192.168.5.1, correct?

    But does tracert to 192.168.5.20 have only a response from 192.168.1.1? If so, the packets from the trace are likely reaching the remote network, as you typically would not see a trace response from the LAN interface of the remote router when you ping a remote host.

    If a tracert to 192.168.5.20 has no responses at all (not even the local router's LAN ip) than first thing I would check the local pc's routing table.

    Possible causes:
    - Routing table has incorrect info. Easy to check, but perhaps not likely problem as you can ping/trace to remote LAN interface.

    - Software on host preventing ping response.

    - Access list (inbound) on router LAN interface blocking icmp response. I've had this happen when working with vpn's.

    - Routing tables on remote host computers are bad. Easy to check, use route print.

    Since the Netgear routers have lousy diagnostics there doesn't seem to be much you can do to directly check that packets are being routed and encapsulated correctly. But a good idea (time permitting) would be to install a sniffer on a remote host and capture everything coming out of the remote router's LAN interface when you ping a remote host. At least then you could see if the packets were being put on the remote LAN.

    Spice_Weasel
     
    Certifications: CCNA, CCNP, CCIP, JNCIA-ER, JNCIS-ER,MCP
    WIP: CCIE
  20. Sparky
    Highly Decorated Member Award 500 Likes Award

    Sparky Zettabyte Poster Moderator

    10,718
    543
    364
    Yup, that’s exactly the problem Im having just now. I have disabled all security software on the remote client when I was testing with ping just to rule out any firewall blocking. According to Netgear there isn’t any rules I can use for the VPN tunnel so I couldn’t block ICMP requests even if I wanted to. Tomorrow I will arrange remote desktop on the server so I can do some ping tests from there as the Netgear diags are flakey at the best of times. Also both sites are miles away from where I’m based so this isn’t helping!

    Is there any free packet sniffer utilities I could use? Or perhaps a 30 day trial?

    Just logged onto the router via remote management to have another look at the config, the tunnel has dropped again, its making me think even if I get it working the stability will be an issue. I do want to get it working though! :biggrin
     
    Certifications: MSc MCSE MCSA:M MCSA:S MCITP:EA MCTS(x5) MS-900 AZ-900 Security+ Network+ A+
    WIP: Microsoft Certs

Share This Page

Loading...
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.