Topic: Allow PPTP *and* VPN passthrough?

[judgej]

This is a problem I have been scratching my head over for a while, and only just managed to fathom out. It affects SME 5.5 and 6.0.1 (possible 7).

Basically, I would like to be able to do two things at once with the SME as a router:

- Allow romote connections using PPTP to the SME server (incoming VPN support).
- Allow internal machines to connect to remote VPNs using their Windows built-in VPN support (VPN passthrough/passthru support).

It seems I can have one or the other, but not both. If incoming PPTP is enabled, then the SME server does not allow a VPN passthough. An internal Windows PC, attempting to connect to an external VPN (I've tried another SME server and a Vigor router) gets the ubiquitous 'Error 721'. If the SME server incoming PPTP support is turned off, then it works immediately.

My situation is that I need to VPN into various client sites from my office, passing through the SME server in server/router mode. While on client sites, I need to do the opposite: to VPN into my office server to pick up documents. It seems the server can be set up to do one or the other, but not both.

Is there some setting that will allow both, or is there some fundamental flaw in the way VPNs work that prevents this being done? Or perhaps this is a bug? I've not seen this particular problem described before (just the odd "I can't VPN into another server from my PC" posting, with no resolutions).

-- Jason

PS I can't keep turning PPTP support on my office server on an off, depending on where I am located that day. For one, it is impracticle, but most importantly, I am not the only one using the server - other poeple need to be able to VPN in at any time. And yes, I am using the term 'VPN' as a verb

[hanscees]

PS I can't keep turning PPTP support on my office server on an off, depending on where I am located that day. For one, it is impracticle, but most importantly, I am not the only one using the server - other poeple need to be able to VPN in at any time. And yes, I am using the term 'VPN' as a verb

I do not know the direct answer. But you might try putting all denylogging on (see faq), and posting back the drop logging form messages.

Hans-Cees

[judgej]

...you might try putting all denylogging on (see faq), and posting back the drop logging form messages...

I've tried searching for 'denylogging', but can't find any references to it. Is there some other name for what you are refering to? I'd like to make sure I'm switching on the right logs.

I did try searching through all the logs in both my gateway SME server and the remote VPN server, to no avail. There was basically nothing in the SME server logs, but the remote VPN showed there was an initial connection attempt, and then it all goes dead.

-- JJ

PS Perhaps you meant this FAQ in the installation section:

http://no.longer.valid/phpwiki/index.php/SecurityFAQ#firewall3

Strangely, it seems to be working now on this SME5.6 machine. I enabled the logging, as described, and set the PPTP clients back from 0 to 3, and VPNs tunneled through the SME server with no problem. I turned the logging off, and it still seems to be holding up. I don't know whether the signal-event on the firewall somehow resets something that had gone out-of-kilter, but for now at least it seems to be working.

I'll keep my eye on this one, as I am not fond of problems like this kind of righting themselves with no obvious reason - they always come back to bite me at a later date!

One thing I am not sure about, is exactly which log file the refused packets should be logged to. The log file names are cryptic at the best of times (e.g. if you already know that 'squid' is a web cache, then you would know which log file to look at to view the web cache, but if you didn't, then you would have a hard time finding what you are looking for - perhaps a FAQ is needed on exactly what all those log files are?).

PPS Not quite fully working: I can VPN through my SME 6.0.1 to a Vigor router, but not to a remote SME 6.5 with PPTP enabled. I'll check that machine out on Monday in case it is not configured correctly.

[judgej]

Getting a bit closer. Although the VPN worked when I went to bed last night, on awaking this morning, it is back to its old non-working mode. The only thing that should have happened overnight is the usual backup and SME's restarting of some processes. Whatever it is, something reconfigures itself each night.

The entries I am now seeing in the 'messages' log are:

Oct 30 09:11:50 sme2 kernel: denylog:IN=eth1 OUT= MAC=00:50:fc:9a:ab:89:00:0c:31:f1:e8:70:08:00 SRC=<remote-ip> DST=<local-ip> LEN=55 TOS=0x00 PREC=0x00 TTL=108 ID=0 DF PROTO=47

Oct 30 09:11:53 sme2 kernel: denylog:IN=eth1 OUT= MAC=00:50:fc:9a:ab:89:00:0c:31:f1:e8:70:08:00 SRC=<remote-ip> DST=<local-ip> LEN=51 TOS=0x00 PREC=0x00 TTL=108 ID=0 DF PROTO=47

Oct 30 09:12:26 sme2 last message repeated 11 times

Where:

<remote-ip> is the IP of the remote router I am trying to VPN into
<local-ip> is the public IP of my local SME box

So, the remote VPN server is trying to get back to me, after an attempt at starting a VPN session, but the SME server is blocking it.

I have tried turning the allowed PPTP connections down to zero, which appeared to make it work yesterday, but is not making a difference now.

I am guessing that somehow the SME server firewall is not matching the returned port 47 datagrams to my PC's original request for a VPN connection, and so is rejecting them as unsolicited. However - sometimes it works, and sometimes it doesn't - making this very difficult to trace.

-- Jason

[judgej]

Strange. I tried again, while tailing the log, got one packet deny (below), then it connected (presumably no more denies):

Oct 30 09:27:58 sme2 kernel: denylog:IN=eth1 OUT= MAC=00:50:fc:9a:ab:89:00:0c:31:f1:e8:70:08:00 SRC=<remote-ip> DST=<local-ip> LEN=55 TOS=0x00 PREC=0x00 TTL=108 ID=0 DF PROTO=47

I don't think this is related to network traffic, as the traffic is very low at both ends at the moment. Besides, the log shows a definate deny, not a timeout.

-- JJ

[hanscees]

Strange. I tried again, while tailing the log, got one packet deny (below), then it connected (presumably no more denies):

Oct 30 09:27:58 sme2 kernel: denylog:IN=eth1 OUT= MAC=00:50:fc:9a:ab:89:00:0c:31:f1:e8:70:08:00 SRC=<remote-ip> DST=<local-ip> LEN=55 TOS=0x00 PREC=0x00 TTL=108 ID=0 DF PROTO=47

I don't think this is related to network traffic, as the traffic is very low at both ends at the moment. Besides, the log shows a definate deny, not a timeout.

-- JJ

As you may or may not know gre there can be a few problems.

Gre is at the same level as tcp/udp, and is protocol 47 under ip. Therefore you cannot just "nat" it. It has no "ports" as tcp and udp have to nat with.
I know there was a patch in kernel 2.4/iptables  for it in the past. I do not know the current status on this.

But if I understand you right you have problems when pptp on the sme itself is on, right? And you try pptp from the lan to the internet.
I am a bit confused as to your exact setup when you have the logging you show.

On the internet I see rules like:
iptables -A INPUT -i eth0 -o eth1 -p 47 -j ACCEPT

or perhaps for you this should be

#first log inside to outside
/sbin/iptables --append FORWARD -i eth0 -o eth1 -p 47 -m state --state NEW -j LOG --log-prefix AcceptServicesIn

#and then let it out
/sbin/iptables --append FORWARD -i eth0 -o eth1 -p 47 -m state --state NEW -j ACCEPT

#traffic back
/sbin/iptables --append FORWARD -p 47 -m state --state ESTABLISHED,RELATED -j ACCEPT

But I do not know if the traffic coming back will be accepted by the statefull filter rules.

You might try that when you have the problems with pptp from your lan to internet and see if it works.

But that is from quite old  ulrs like:

http://lists.suse.com/archive/suse-security/2003-Dec/0015.html

You might want to examin the output of a command like this:

iptables -vnL
iptables -t nat -vnL

when things work, and when things do not work.

In my understanding I would expect thingd to just work, but reality apparently sais otherwise.

Hans-Cees

[hanscees]

I see these posts on iptables lists:

http://lists.netfilter.org/pipermail/netfilter-devel/2005-September/021514.html

http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=926b50f92a30090da2c1a8675de954c2d9b09732

and am afrian gre natting through the forward chain might be not possible. But you should probably ask some kernel guru's what is compiled in in sme7 kernel and ipnat.

In another post I see this:
ip_conntrack_pptp: Unknown symbol __ip_conntrack_expect_find
ip_conntrack_pptp: Unknown symbol __ip_conntrack_expect_find
ip_nat_pptp: Unknown symbol ip_nat_pptp_hook_inbound
ip_nat_pptp: Unknown symbol ip_nat_pptp_hook_expectfn
ip_nat_pptp: Unknown symbol ip_nat_pptp_hook_exp_gre
ip_nat_pptp: Unknown symbol ip_nat_pptp_hook_outbound

So you might need these ip_nat_pptp things:

/sbin/modprobe ip_nat_pptp
/sbin/modprobe ip_conntrack_pptp

I do not know if they are there.

Hans-Cees

[judgej]

I see (I think) - thanks.

Doing a bit of background reading, I see where GRE fits in the protocol now. I had always assumed it was just another TCP or UDP packet, but as you say, it it neither.

So what should happen, is that the GRE packet is opened up and then the payload unencrypted, and that should provide a PPTP packet to pass on to the next stage in the network. What appears to be happening, is that the IP package carrying the GRE packet is being denied too early, or the kernel is not opening the packet correctly. I expect it is more complicated than that though.

Now (at last) I see why home routers that allow VPN pass-through are different to routers that do not. It is not simply about opening a few ports in the firewall.

So - you think that this is possibly a kernal bug, and that there are fixes out there for later versions? If so, then I think my only option is really to go to SME 7.0 as soon as it is ready. Or perhaps bypass the SME server when I need to VPN.

The setup I have is very simple:

[My PC]---[SME 5.6]---{Internet}---[Vigor Router]---{remote-network}

and this:

[My PC]---[SME 5.6]---{Internet}---[SME 6.0.1]---{remote-network}

and this:

[My PC]---[SME 6.0.1]---{Internet}---[Vigor Router]---{remote-network}

and this:

[My PC]---[SME 6.0.1]---{Internet}---[SME 6.0.1]---{remote-network}

'My PC' is a laptop, and I use it in a number of locations. In each case, I just want my laptop to join the remote network to access machines on that network.

I'll study the output of those IP chains commands too, and see if I spot any differences when it works/not.

-- Jason

[hanscees]

I see (I think) - thanks.

Doing a bit of background reading, I see where GRE fits in the protocol now. I had always assumed it was just another TCP or UDP packet, but as you say, it it neither.

So what should happen, is that the GRE packet is opened up and then the payload unencrypted, and that should provide a PPTP packet to pass on to the next stage in the network. What appears to be happening, is that the IP package carrying the GRE packet is being denied too early, or the kernel is not opening the packet correctly. I expect it is more complicated than that though.

Hmm, not quit.

Your pc and some host on the internet exchange both GRE and tcp 1723 packets, and that is what is needed for the tunnel.

So from your pc goes a ip/gre packet to internet. It has an ip like 192.168.1.2 or something similar. That must be natted by your sme server to an internet-routable ip.
Since port-natting is no option it must use some other means of doing that.

Then a gre packet will come back from the host on internet you tried to connect to. The sme firewall must know there is a standing ip/gre connect. If it does not, it will think the gre connect is for itself. And then it denies it in the input chain. And that is what seems to be happening.

Remember, in iptables traffic for the sme itself goes to the input/output chains, traffic going through it will go through the forward chain.

You can probably set up a sort of port-forward rule
for gre, but only for one ip address I think.
Unless that contrack module works.

Therefore I was wondering if the pptp does work from your lan to internet if you have pptp "off" on the sme itsself.
That would be odd.

Now (at last) I see why home routers that allow VPN pass-through are different to routers that do not. It is not simply about opening a few ports in the firewall.

So - you think that this is possibly a kernal bug, and that there are fixes out there for later versions? If so, then I think my only option is really to go to SME 7.0 as soon as it is ready. Or perhaps bypass the SME server when I need to VPN.

my sme7 says:


[root@mail ~]# /sbin/modprobe ip_nat_pptp
FATAL: Module ip_nat_pptp not found.
[root@mail ~]# /sbin/modprobe ip_conntrack_pptp
FATAL: Module ip_conntrack_pptp not found.
[root@mail ~]#


So  I would not count on it working to much. Although I might be wrong and it could be in the kernel already.


greetings

Hans-Cees

[judgej]

This is getting stranger and stranger.

I am sat on the inside of an SME 6.5 server/gateway and trying to VPN out to two other networks.

- I can VPN out through the SME 6.5 box, direct to an SME 6.0.1 box.
- I cannot VPN out through the SME 6.5 box to a Draytek Vigor router.

When I turn the PPTP clients in the 'remote access' menu of the SME 6.5 down to zero, I see the protocol 47 packet rejections in the deny log. When I make the PPTP clients 1 or more, then there is nothing in the deny log. However, in both cases, my machine on the inside of the network is giving me the '721' error (i.e. the protcol 47 messages are not getting through it it).

From within an SME 6.0.1 server/gateway network, the same laptop *can* VPN to the Vigor router.

So the questions are:

- Why can I VPN to some hosts through the SME 6.5 but not others, when I know I can VPN to all those hosts from other locations?

- Why should SME 6.5 allow VPN passthrough for one destination host, and yet try to catch and/or deny the VPN for another destination host?

I have to add that 6.5 is causing me the most problems here. 6.0.1 is intermittently troublesome, but does work if you attempt to VPN enough times.

-- Jason