VPN tunnel creation

[otpayne]

Hi,

First post so be gentle.

We have NTL business broadband installed at one of our sites and are using this for VPN tunnels back to head office. We asked for fixed IP addresses to enable this, however NTL seem to have a different idea of a fixed IP address to the rest of the planet. Basically the IP is leased to a mac address, this has caused us no end of problems. However the basic problem seems to be that because of this NTL uses some for of transparent proxy for the IP address.

Now we coome to the problem. When the tunnel is created on our firewall it checks the source IP address of the package and tests it agianst the endpoint of the ip tunnel. Because our device is relatively intelligent it detects the ip address of the proxy as the end point of the tunnel and fails to create the tunnel as the proxied ip address and source ip are different. After hours of talking to the trained chimps at NTL who have kindly every time told us that thye have proved connectivity and that the call is ended. We have not managed to get any further with NTL and therefore cannot use tunnels. Why can't NTL assign fixed IP's like everyone else and why the hell do they proxy on business essential accounts when they know that people will be tunnelling etc on these types of accounts. Does anyone have any advice on how to get around this or if they have managed to get this turned off for their business broadband accounts?:mad:

[SMHarman]

I think - though an no expert on this one - you have just explained how NTL provide a static IP address in their dynamic world and from what you are saying the using that address will be insurmountable unless your device can be told to override in this instance.

Their dynamic IPs are pretty static if you have a router on the end of it. Can you route to that - you will then need to do some kind of daily check to ensure the address has not changed, but it just might work.

[altis]

I don't see why the proxies are involved. They only cache HTML traffic on port 80. VPN traffic is on port 500 (if memory serves) and will simply bypass them.

My limited experience of VPNs (using some Netgear FWG114Ps) suggests that it should be possible to set up a FQDN (fully qualified domain name) using dyndns.org or somesuch and use that instead of the IP addy. It works fine for me.

[Chris]

Hi,

First post so be gentle.

After hours of talking to the trained chimps at NTL who have kindly every time told us that thye have proved connectivity and that the call is ended.

<snipped>

We'll be gentle with you provided you're gentle with the 'chimps' as you call them ... several highly qualified NTL staff post on here in their own time and they can be very helpful when asked nicely and not insulted. ;)

:welcome: to Cable Forum by the way.

[Millay]

I would look at dyndns or no-ip.com to. also, would look at the way your VPN is set up, as you can with certain VPN systems route all traffic over port 80 and this can cause you to have this problem.

[Nemesis]

I have run VPN from Home NTL connection, via Cisco VPN software through to Cisco Pix Firewall, with none of these issues at all.

[BBKing]

I've seen this crop up before - the VPN software initiates the connection via HTTP on port 80, which is intercepted by the proxy and the VPN terminator at the far end isn't intelligent enough to spot the difference between a proxy and client IP (mind you, neither are slashdot). Other VPN solutions that don't use port 80 at all are unaffected (including Cisco VPN, which we use at ntl, in fact).

Static IPs aren't available on cable - business get pseudo static IPs where your MAC is guaranteed the same address in the pool as long as that pool is allocated to your area, but obtaining the IP is done over DHCP (otherwise the UBR will reject the traffic).

[otpayne]

The highly qualified guys are usually very helpful, however after several phone calls and nearly an hour and a half on hold to be told by the it support guy at the end of the line that they have proved connectivity and that they cannot help anymore, you will understand the frustration we experience( and this has happened on several occassions). The device we are having problems with is a fortigate firewall etc. On BT lines we have no problems as they do actually statically assign IP's. However even though we requested a static IP and were told by the sales guys that we would have them we appear not to have a static IP and this is what is causing the problem I believe. We have managed to create this by routing the traffic to a draytek that creates the VPN, however if we try to route from fortigate to fortigate no luck. Is there anyway that we could get business essentials to actually assign an IP address and remove whatever is assigning the other IP address so that we can operate as we would through any other ISP.
__________________

And btw way I worked for NTL briefly in cleppa park in the dim and distant past when their isp helpdesk was there, so I know that some of the guys are brilliant at what they do but I also realise that some of the people are not as good and work to almost impossible targets etc.
__________________

I also have trouble understanding why any other IP would be seen for this. I have checked the logs and it seems as though the vpn is a traditional vpn ( port 500 etc ) so I don't understand why it would see the destination IP as different than the source. Can someone explain to me how NTL handle the routing of the IP's. I understand that it is different in some areas and that they don't have this issue ( manchester is different I believe) I'm in cardiff. If there is nothing I can do about this I am going to move from NTL to something that I know works and get yet another refund from NTL (I'm on about my third refund at the mo. I would understand a proxy for web traffic but why for IP traffic?

[Graham M]

Because usually when VPN connections are requested it is done thru port 80, the NTL Transparent caches grab everything on Port 80 and Proxy it, the Proxies which are just meant to handle web requests and web pages will not know what to do with this request and discard/scramble it. If it does manage to pass it on, the destination computer might not realise that the connection has been proxied and send an request for identification or whatever to the proxy

[otpayne]

That sounds logical,bugger! Don't rate my chances of getting
a: through to the helpdesk within a sane time period
b: getting someone who knows about this issue
c: getting them to suggest anyways around this.

[Paul]

Don't initiate the connection over tcp port 80 - you should be able to configure this in the vpn software.

[Andy E]

Why don't you use no-ip.com. Register with them , download the
dynamic update client and setup the vpn using the dynamic dns setup on the draytek

set the service provider to www.no-ip.com (http://www.no-ip.com)
set the service type to dynamic
and the domain name to whatever you've registered with no ip

works a treat ... im using it right now to do some work on a win 2k3 server


Andy E
ntl pirate

[otpayne]

I'm trying to lose the draytek out of the equation and just have fortigate to fortigate. Fortigate has no settings for not initiating on port 80. On the log the phase 1 traffic is initiated on port 500 not port 80 which confuses me as surely I would see the tunnel being initiated on port 80 if it was the transparent proxy that was causing this problem. on the fortigate we have two interfaces one we are reserving for intersite comms and one for webtraffic etc, both have ntl business essential lines on them. and we are routing traffic through the fortigate hence the requirment for it to be there. However at the mo I have the fortigate routing to the draytek which brings the tunnel up no problem. But the minute I take the draytek out the tunnel is failing to create from fortigate to fortigate. need to do some more research into this. :erm:

[Paul]

Port 500 (udp) would be the standard (followed by establishing a connection using ESP/IP). If this is what you are using then the proxy servers are out of the equation.