Cablecom hispeed business blocks GRE packets
This weekend, my plan was to upgrade our internet connection from an aging ADSL-Line to a new ADSL2+ line from Cablecom. At the same time, i also replaced our aging, self built Linux Firewall/Reverse-Proxy/etc. with a SonicWALL NSA3500.
Up until now, we’ve been using PPTP for our VPN needs. PPTP is easy and painless to setup, but can cause several problems on customers site because it needs GRE. Many overzealous firewalls block GRE.
In the future, we are intending to use SonicWALLs Global VPN Client, that uses IPsec with it’s NAT-Traversal over UDP. Also, the SonicWALL GVC solution is able to plug directly into Active Directory for central authentication.
I intended to keep PPTP running for some time after the migration, in order to ease the transition. But as it looks now, Cablecom blocks OUTBOUND GRE packets. Mighty strange, because inbound GRE-Packets work.
Here’s how this looks in tcpdump:
10:58:13.927888 IP 77.59.216.227 > 194.88.212.200: off 0×5858 [|gre]
10:58:13.947131 IP 77.59.216.225 > 77.59.216.227: icmp 52: host 194.88.212.200 unreachable
.225 is the Cablecom CPE, and .227 is the Linux machine running the PPTP server.
I’ve already opened a support case with Cablecom, in the hope of having this issue sorted out quickly. So far, i haven’t heard back from them, even though i reported the issue almost a day ago. It’s not like we pay 180 CHF a month for 24/7 support.
Update: Cablecom was able to resolve the issue today. Apparently, it was a config issue on the router.
mousseman:
Hmmmm….so I’m not the only one who noticed this? How surprising.
I had the same splendid idea one day to use PPTP as we have lots of people with Windows XP and setting up PPTP is the most painless way to connect to our network, seen from the client side.
The inbound site is on a cablecom business network, with an IP rather close to yours, and our firewall is from Cisco. And I know for sure that a Cisco PIX does not block GRE by itself (and it’s left to the really enterprising readers to devise an ACL to do so).
Does your connection use Cisco CPE, or some other brand?
17. August, 2008, 12:37Lukas Beeler:
Hi,
We have an Alcatel CPE, access technology is ADSL2+.
Do you have a Cisco CPE or are using some other access technology?
If other CPEs didn’t have the same behaviour, it would be a pretty clear cut case of human error (though i’d wonder how you make such a mistake). But if other CPE also blocks GRE, then there must be some reason behind it.
17. August, 2008, 13:03mousseman:
We have NexComm NBG400 CPE, plus a Cisco 2600. Now I heavily suspect the NexComm isn’t the culprit, so this leaves the Cisco 2600. Same symptoms down here:
- inbound GRE seems to work, as PPTP VPNs work
- PPTP conection to a customer VPN doesn’t work
- Cisco IPsec workds dandy
If I can petition CC to give me access to the 2600, I’d know withhin minutes.
18. August, 2008, 08:55Lukas Beeler:
Hi,
Hmm, it looks like you are experiencing a different problem than i did.
PPTP always needs in- and outbound GRE packets to work. No matter if they’re incoming or outgoing connections. In my case, ALL outgoing GRE packets were blocked (no matter if they originated from a client or a server).
Are your clients that try using PPTP behind NAT? If so, the problem is most probably your NAT device.
19. August, 2008, 22:46mousseman:
Update: PPTP VPNs don’t work into any direction anymore. According to a non-Citrix-User (i.e. client-2-site VPN user), it stopped working about three monthes ago.
First, he blamed it onto his UMTS connectivity in Germany (the cell providers have some really funky routing), but then I went down to a ‘known good’ ADSL connection, and it still didn’t work.
However, if I use the WAN subnet with routable IPs, attached to a switch, where the WAN port of the PIX and the Cisco 2600 is attached, it works. Obviously because it doesn’t pass through the 2600.
The NAT question is moot since the VPN endpoint is the PIX WAN interface, and it’s IP is routable (some 77.200.*).
20. August, 2008, 01:20Lukas Beeler:
mousseman,
You can run hping2 -0 -H 47 -d 10 194.88.212.200. You should receive ICMP Packets from 194.88.212.200 “proto unreach”.
However, it is most likely that you will get the same host unreach message as i got, from one of your Cablecom devices. Tell that to support, and the issue should get resolved rather quickly
20. August, 2008, 08:27cablecom hispeed business sucks » Lukas Beeler’s IT Blog » Blog Archive:
[...] after installing the line back in 2008, we’ve ran into an issue wherecablecom hispeed business blocks GRE packets. After almost three days and speaking with a variety of technicians, they were finally able to [...]
8. January, 2010, 22:04