I'm struggling to get a MS PPTP VPN working through a Linux IPChains firewall (IPCop). The intial connection (TCP 1723) is being masqueraded but the source port is being translated to a high port (>61000). Connections work fine direct or through an IOS firewall (which keeps the original Source Port).

For some reason it appears the firewall at the other end of the VPN doesnt seem to like he high source port. I have no access to check/change this so need to persuade the IPChains firewall to leave the source port alone (unless there is a conflict).

The IPChains box is only sharing an ISDN connection for a small home network (my Parents) so conflicts should be rare.

Anyone know how to get IPChains to use the original Source Port ?

Thanks
Deano

 

*cough* anybody ?

 

Do you have an IP range external to the Linux firewall that you could NAT you PPTP connection ?

This is typically how HIDE (or Dynamic) NATing works to allow it to now which internal host orginated the packets (ie changing the source port). Firewalls tend to be critical of the destination port rather than the source. Do you know what the device is that you are trying to terminate the PPTP tunnel to is ?


Jeff

 

Jeff

Its a single dynaminc (standard PPP dial-up) external IP. VPN terminates on standard MS server behind a FW-1. Both the FW-1 and VPN server are my Dad's corporate infrastructure so no possibility to check/change configurations.

The *only* difference I can see between a connection that works (direct or via IOS F/W) and one that doesnt (via IPCop) is that IPCop routinely changes the source port. IOS doesn't. Same Client/Same destination/Same dial-up account/same config etc.

The TCP dest port 1723 control connection never seems to complete so I get no login prompt and it doesnt get anywhere near building the actual VPN tunnel.

Deano

 

Doesn't MS VPN us GRE? does IPMASQ even forward that? I've done WinXP to PPTP server with my source port through a NAT that remapped the source port, no problem, I would be looking on the external interface to see if you can see any GRE packets at all.

 

D'oh! lagged reply, ignore that is the TCP connection to 1723 doesn't even complete

 

I would have thought that it would be simpler to use Secureremote or Secureclient on the client into the FW-1 rather than messing around with the nasty stuff that Microsoft claim as VPN software...but heh, each to their own.

I don't know enough about IPCop to give you an answer to this one....Sorry.

And I don't think that MS VPN uses GRE either.....


Jeff

 

Have you asked the question here ...

http://ipcop.hopto.org/



Jeff

 

Sorry, it's specfically PPTP that uses GRE, not all MS VPN's

 

Does it ?? I thought that GRE was a specific Cisco thing....learn something new everyday !


Jeff

 

From here, but when did MS ever follow standards?

 

Deano, does this help?

 

ipchains always remaps the source port by default. Are you certain that the problem is the source port is not port 1723 or because the remote machine is sending back a connection on another predefinded port which is being rejected (like ftp protocol???).

There are a number of modules you can load to do special stuff (TM). I cant remember if there is a generic module or if you will need to write your own. The bundled modules are installed under /lib/modules/<kernelver>/????/ip_masq_?????

Will see what else I can find

 

Does this help?

http://www.impsec.org/linux/masquerade/ip_masq_vpn.html

 

I've done TCPdumps on the Ethernet and ppp0 interfaces and the control connection (source port 61000 to dest port 1723) never gets a single reply. - not even the first syn/ack. Like I said the same client talking to the same server but through an IOS based firewall works just fine

I'm 99% sure the "problem" is at the corprate firewall in that it is dropping the connection. however I have zero ability to change or check that. (its a smallish compnay who simply dont have the expertise to troublshoot or adjust their firewall just to let a single user do something different). So I need to a) adjust this end b) use something else. (RR may yet get a sale )

have read all the masquerade/vpn links I've checked and the pptp module is loaded and being used. I've even set up a VPN server at home and connected through the IPCop box to it. So its the interaction between the IPCop and the far end - of which I can only change this end.

Looks like I might be flogging a dead horse. I've tried Smoothwall 0.99 and that behaves the same. I'll give Smoothwall beta 2 a go tonight.

Deano

 

Have you installed the patches from the link above? If not why not

If that does not fix the problem and the connection is going out on a different dst port I should be able to hack a quick module together to always allocate the same dest port.

 

Rob

I'm not into patching - I dont have a clue how to start IPCop is a cut down distro so I'd need to build a kernel on a matching full distro and move it i guess. Dest port (1723) is fine. Its the source port that I believe is causing the problem. I'm only going to spend so much time saving my Dad the cost of a decent small ISDN router . At the moment I think I might be able to blag another cisco 1603....

Many Thanks for the links though.

Deano

 

Could try this

 

Have you had a butcher's here : http://www.quarkav.com/SmoothWallGPL/SWG_vpn_1.1.php


Personally I'm using a CP-FW1 client to make the connections, not the firewall itself.

Steve