0

I have replaced a mess of Cisco routers with a single Dell PowerConnect 6224. These routers serve (and served) public IPs to clients, and just acted as routers to the upstream provider.

Prior to the replacement, a customer had a VPN appliance that used GRE and IPsec to connect back to their head office.

Prior to the change, the network looked like:

Customer -> cisco -> cisco -> internet

Now it looks like 

Customer -> 6224 -> internet

(The IP space that the customer is using has also changed.)

The 6224 was selected for routing duties as the new connection has a datarate of 150Mb/s and the operator of the network did not want to limit themselves to the 100Mb/s that the ciscos would provide. Upgrading the capability of the ciscos (or rather, replacing them with ciscos with the required data rate) was considered too expensive; the 6224 was selected instead.

The customer uses the 6224 as their next-hop to the internet. It is acting as a router -- there are no ACLs or firewall rules or anything like that going on.

After the customer has reconfigured their VPN device, they can no longer connect to it over the internet.

Other customers, using what I presume are standard IPsec VPNs, are operating on the same link without incident.

We have confirmed the IP parameters by replacing the VPN device with a XP laptop. With the same parameters, the laptop can use the internet, and is reachable from the internet as would be expected.

My question: does the 6224 (or whatever router is doing this job) have to understand GRE in order for the connection through it to work? Was there some on-by-default-magic in the Ciscos that was handling this for me?

Failing that, is there anything else obvious I should be looking at to figure out why their VPN device does not work?

David Mackintosh
  • 14,223
  • 6
  • 46
  • 77

3 Answers3

1

If the 'router' is not trying to do any kind of NAT or stateful packet filtering then it should not need to know anything above the IP layer. This means a router should not know or care about GRE and should pass IP traffic just fine.

To help you diagnose this you might want to fire up wireshark one side of the connect and then run packETH (windows) at some other location. Generate GRE traffic and target the box running wireshark.

Zoredache
  • 128,755
  • 40
  • 271
  • 413
  • This is correct. My issue turned out to be that the customer reconfigured their device from the other side of the world and had a finger problem. They shipped a replacement device, configured at their end, and it worked flawlessly. – David Mackintosh Dec 20 '10 at 04:09
1

We have confirmed the IP parameters by replacing the VPN device with a XP laptop. With the same parameters, the laptop can use the internet, and is reachable from the internet as would be expected.

So you're saying that the XP laptop is configured as the VPN endpoint with the same parameters as the VPN device and that the laptop works and VPN connections from the outside are able to be established to the laptop? If so, then I'd say that should be telling you that the 6224 is not the problem. Have you checked all of the settings on the VPN device to make sure they're correct? How about setting up the VPN device from scratch and trying again?

As a switch, using it's out of the box configuration, the 6224 doesn't know and shouldn't care about the traffic that's passing through it. As a router though I'm not sure. To be perfectly honest, I'm having a little trouble imagining what the network looks like without a proper router between the customer and the upstream provider. What device provides inbound\outbound security, NAT, etc.?

joeqwerty
  • 108,377
  • 6
  • 80
  • 171
  • Actually no, the XP device did not reproduce the VPN endpoint, only the networking parameters. The far end of the intended VPN tunnel could ping the XP laptop correctly. To my mind, this proves that the layer 3 configuration is correct end-to-end. – David Mackintosh Oct 08 '10 at 12:59
  • True enough but then your problem wasn't with IP connectivity it was with the VPN connection so the Windows XP test, in the end, doesn't prove anything in terms of resolving your issue. Are you able to set up a different VPN endpoint as a test to rule out the VPN device? – joeqwerty Oct 08 '10 at 13:24
-1

If the end-point devices require GRE, then the intermediate devices will also need to support GRE too.

user48838
  • 7,393
  • 2
  • 17
  • 14
  • I don't believe that's strictly true. Millions of VPN connections are completely operable via plain vanilla layer 2 switches every day. – joeqwerty Oct 08 '10 at 09:54
  • The 6224 is a layer 3 device in this scenario. – David Mackintosh Oct 08 '10 at 12:58
  • Not all VPNs utilize GRE, actually a lot of the modern VPN technologies have moved away from GRE. GRE is classified as a Layer 5 protocol that encapsulates Layer 3 protocols. – user48838 Oct 08 '10 at 13:14
  • I need to clarify/further qualify my initial statement to intermediate Layer 3 devices due to the Layer 3 functionality/interoperability/payload of GRE. – user48838 Oct 08 '10 at 13:16