PPTP passthrough

PPTP passthrough

[Steven O'Connor]

PPTP pass-through seems to be broken. When the client tries to connect, 
a gre packet is sent but the reply gre packet is dropped at my firewall.

The relevant conntrack dump shows a mismatch between the expected reply 
and the packet received, srckey/dstkey do not match. Is that significant?


gre      47 27 src=aaa.bbb.cc.ddd dst=www.xxx.yy.zz srckey=0x0 
dstkey=0xb053 [UNREPLIED] src=www.xxx.yy.zz dst=aaa.bbb.cc.ddd 
srckey=0xb053 dstkey=0x0 mark=0 use=1
gre      47 27 src=192.168.0.212 dst=aaa.bbb.cc.ddd srckey=0x0 
dstkey=0x1380 [UNREPLIED] src=aaa.bbb.cc.ddd dst=www.xxx.yy.zz 
srckey=0x1380 dstkey=0x0 mark=0 use=1


-- 
Steven O'Connor
=============================================
Support Services Pty Ltd   ABN 49 006 226 428
2 Commonwealth Terrace, Sandhurst VIC 3977
Fax 03 9888 2677, Mobile 0417 571 113
=============================================

Re: PPTP passthrough

[Robert White]

On 05/03/17 02:13, Steven O'Connor wrote:
> PPTP pass-through seems to be broken. When the client tries to connect,
> a gre packet is sent but the reply gre packet is dropped at my firewall.
> 
> The relevant conntrack dump shows a mismatch between the expected reply
> and the packet received, srckey/dstkey do not match. Is that significant?
> 
> 
> gre      47 27 src=aaa.bbb.cc.ddd dst=www.xxx.yy.zz srckey=0x0
> dstkey=0xb053 [UNREPLIED] src=www.xxx.yy.zz dst=aaa.bbb.cc.ddd
> srckey=0xb053 dstkey=0x0 mark=0 use=1
> gre      47 27 src=192.168.0.212 dst=aaa.bbb.cc.ddd srckey=0x0
> dstkey=0x1380 [UNREPLIED] src=aaa.bbb.cc.ddd dst=www.xxx.yy.zz
> srckey=0x1380 dstkey=0x0 mark=0 use=1
> 
> 
Doesn't help without your firewall rules.

Do you have a expected,related,established rule in your outgoing chain?

The private address (the only one you didn't blank) suggests that some
SNAT rule is just a little too ambitious for your own good.

One of the things I do is limit SNAT rules to packets that come from
real internal-network interfaces. (I use interface group numbers or
wildcards to make that easier.) Basically you probably don't want to
SNAT any the packets generated by the local machine.

Re: PPTP passthrough

[Steven O'Connor]

On 03/05/17 20:38, Robert White wrote:
> On 05/03/17 02:13, Steven O'Connor wrote:
>> PPTP pass-through seems to be broken. When the client tries to connect,
>> a gre packet is sent but the reply gre packet is dropped at my firewall.
>>
>> The relevant conntrack dump shows a mismatch between the expected reply
>> and the packet received, srckey/dstkey do not match. Is that significant?
>>
>>
>> gre      47 27 src=aaa.bbb.cc.ddd dst=www.xxx.yy.zz srckey=0x0
>> dstkey=0xb053 [UNREPLIED] src=www.xxx.yy.zz dst=aaa.bbb.cc.ddd
>> srckey=0xb053 dstkey=0x0 mark=0 use=1
>> gre      47 27 src=192.168.0.212 dst=aaa.bbb.cc.ddd srckey=0x0
>> dstkey=0x1380 [UNREPLIED] src=aaa.bbb.cc.ddd dst=www.xxx.yy.zz
>> srckey=0x1380 dstkey=0x0 mark=0 use=1
>>
>>
> Doesn't help without your firewall rules.
>
> Do you have a expected,related,established rule in your outgoing chain?
>
> The private address (the only one you didn't blank) suggests that some
> SNAT rule is just a little too ambitious for your own good.
>
> One of the things I do is limit SNAT rules to packets that come from
> real internal-network interfaces. (I use interface group numbers or
> wildcards to make that easier.) Basically you probably don't want to
> SNAT any the packets generated by the local machine.
>
>
>
>
I'm not using any SNAT only masquerade.

The default policy LAN->NET is accept. I have also added a rule to 
accept gre.

It has been working previously but after an update to the kernel or 
shorewall it has stopped working.  I only use pptp occasionally so I 
cannot be sure when it stopped.

The firewall can accept pptp connections from the net and it is only the 
passthru that is broken.


-- 
Steven O'Connor
=============================================
Support Services Pty Ltd   ABN 49 006 226 428
2 Commonwealth Terrace, Sandhurst VIC 3977
Fax 03 9888 2677, Mobile 0417 571 113
=============================================

Re: PPTP passthrough

[Robert White]

On 05/04/17 03:46, Steven O'Connor wrote:
> I'm not using any SNAT only masquerade.

Masquerade _is_ SNAT, abet with automatic network address selection and
connection tracking "forgetting" features, so the same caveats apply.
You should _not_ let the SNAT (masquerade) touch the packets that
originate on the local host. It's "usually fine" but it can get a little
iffy in some corner cases since it's a greedy modification of packet
contents.

Though Pascal's comment about needing to assign the helpers to your
connection is probably more on target.

I'd still make sure that you are only applying the address rewrite rules
via explicit limit of the rule by using explicit mention of both the
obvious --out-interface and the highly recommended --in-interface selectors.

ASIDE: I, long ago, started using ext+, int+, and loc+ as interface
names. ext+ are external-facing interfaces. int+ are internal interfaces
such as bridges and such. loc+ are real interfaces that don't get their
own addresses because they'll end up inside a bridge or bond or
whatever. I'm migrating to group id numbers with higher numbers being
assigned to loc+ than int+ and than ext+ respectively so that in
nftables I can use group ID greater-than/less-than X rules.

But anyway, you should only SNAT things that don't already have the
correct structure if you want to avoid some potential messes.

Re: PPTP passthrough

[Rob Sterenborg (lists)]

On 3-5-2017 04:13, Steven O'Connor wrote:
> PPTP pass-through seems to be broken. When the client tries to connect,
> a gre packet is sent but the reply gre packet is dropped at my firewall.
>
> The relevant conntrack dump shows a mismatch between the expected reply
> and the packet received, srckey/dstkey do not match. Is that significant?
>
>
> gre      47 27 src=aaa.bbb.cc.ddd dst=www.xxx.yy.zz srckey=0x0
> dstkey=0xb053 [UNREPLIED] src=www.xxx.yy.zz dst=aaa.bbb.cc.ddd
> srckey=0xb053 dstkey=0x0 mark=0 use=1
> gre      47 27 src=192.168.0.212 dst=aaa.bbb.cc.ddd srckey=0x0
> dstkey=0x1380 [UNREPLIED] src=aaa.bbb.cc.ddd dst=www.xxx.yy.zz
> srckey=0x1380 dstkey=0x0 mark=0 use=1

You don't show any rules, so just a guess.
Do you allow/forward protocol 47 (gre) packets?


--
Rob

Re: PPTP passthrough

[Steven O'Connor]

On 04/05/17 00:45, Rob Sterenborg (lists) wrote:
> On 3-5-2017 04:13, Steven O'Connor wrote:
>> PPTP pass-through seems to be broken. When the client tries to connect,
>> a gre packet is sent but the reply gre packet is dropped at my firewall.
>>
>> The relevant conntrack dump shows a mismatch between the expected reply
>> and the packet received, srckey/dstkey do not match. Is that 
>> significant?
>>
>>
>> gre      47 27 src=aaa.bbb.cc.ddd dst=www.xxx.yy.zz srckey=0x0
>> dstkey=0xb053 [UNREPLIED] src=www.xxx.yy.zz dst=aaa.bbb.cc.ddd
>> srckey=0xb053 dstkey=0x0 mark=0 use=1
>> gre      47 27 src=192.168.0.212 dst=aaa.bbb.cc.ddd srckey=0x0
>> dstkey=0x1380 [UNREPLIED] src=aaa.bbb.cc.ddd dst=www.xxx.yy.zz
>> srckey=0x1380 dstkey=0x0 mark=0 use=1
>
> You don't show any rules, so just a guess.
> Do you allow/forward protocol 47 (gre) packets?
>
>
> -- 
> Rob
>
> -- 
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

The default policy LAN->NET is accept. I have also added a rule to 
accept gre.

It has been working previously but after an update to the kernel or 
shorewall it has stopped working.  I only use pptp occasionally so I 
cannot be sure when it stopped.

The firewall can accept pptp connections from the net and it is only the 
passthru that is broken.


-- 
Steven O'Connor
=============================================
Support Services Pty Ltd   ABN 49 006 226 428
2 Commonwealth Terrace, Sandhurst VIC 3977
Fax 03 9888 2677, Mobile 0417 571 113
=============================================

Re: PPTP passthrough

[Rob Sterenborg (Lists)]

On 04/05/17 05:42, Steven O'Connor wrote:
> On 04/05/17 00:45, Rob Sterenborg (lists) wrote:
>> On 3-5-2017 04:13, Steven O'Connor wrote:
>>> PPTP pass-through seems to be broken. When the client tries to connect,
>>> a gre packet is sent but the reply gre packet is dropped at my 
>>> firewall.
>>>
>>> The relevant conntrack dump shows a mismatch between the expected reply
>>> and the packet received, srckey/dstkey do not match. Is that 
>>> significant?
>>>
>>>
>>> gre      47 27 src=aaa.bbb.cc.ddd dst=www.xxx.yy.zz srckey=0x0
>>> dstkey=0xb053 [UNREPLIED] src=www.xxx.yy.zz dst=aaa.bbb.cc.ddd
>>> srckey=0xb053 dstkey=0x0 mark=0 use=1
>>> gre      47 27 src=192.168.0.212 dst=aaa.bbb.cc.ddd srckey=0x0
>>> dstkey=0x1380 [UNREPLIED] src=aaa.bbb.cc.ddd dst=www.xxx.yy.zz
>>> srckey=0x1380 dstkey=0x0 mark=0 use=1
>>
>> You don't show any rules, so just a guess.
>> Do you allow/forward protocol 47 (gre) packets?
>>
>>
>> -- 
>> Rob
>>
>> -- 
>> To unsubscribe from this list: send the line "unsubscribe netfilter" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> The default policy LAN->NET is accept. I have also added a rule to 
> accept gre.
>
> It has been working previously but after an update to the kernel or 
> shorewall it has stopped working.  I only use pptp occasionally so I 
> cannot be sure when it stopped.
>
> The firewall can accept pptp connections from the net and it is only 
> the passthru that is broken.

IIRC something changed with autoloading helper modules (don't know 
exactly when): are the PPTP helper modules loaded?

nf_nat_pptp.ko
nf_conntrack_pptp.ko

You would need nf_nat_pptp.ko for NAT-ing the PPTP protocol.


--
Rob

Re: PPTP passthrough

[Rob Sterenborg (Lists)]

On 04/05/17 08:07, Rob Sterenborg (Lists) wrote:
> On 04/05/17 05:42, Steven O'Connor wrote:
>> On 04/05/17 00:45, Rob Sterenborg (lists) wrote:
>>> On 3-5-2017 04:13, Steven O'Connor wrote:
>>>> PPTP pass-through seems to be broken. When the client tries to 
>>>> connect,
>>>> a gre packet is sent but the reply gre packet is dropped at my 
>>>> firewall.
>>>>
>>>> The relevant conntrack dump shows a mismatch between the expected 
>>>> reply
>>>> and the packet received, srckey/dstkey do not match. Is that 
>>>> significant?
>>>>
>>>>
>>>> gre      47 27 src=aaa.bbb.cc.ddd dst=www.xxx.yy.zz srckey=0x0
>>>> dstkey=0xb053 [UNREPLIED] src=www.xxx.yy.zz dst=aaa.bbb.cc.ddd
>>>> srckey=0xb053 dstkey=0x0 mark=0 use=1
>>>> gre      47 27 src=192.168.0.212 dst=aaa.bbb.cc.ddd srckey=0x0
>>>> dstkey=0x1380 [UNREPLIED] src=aaa.bbb.cc.ddd dst=www.xxx.yy.zz
>>>> srckey=0x1380 dstkey=0x0 mark=0 use=1
>>>
>>> You don't show any rules, so just a guess.
>>> Do you allow/forward protocol 47 (gre) packets?
>>>
>>>
>>> -- 
>>> Rob
>>>
>>> -- 
>>> To unsubscribe from this list: send the line "unsubscribe netfilter" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>> The default policy LAN->NET is accept. I have also added a rule to 
>> accept gre.
>>
>> It has been working previously but after an update to the kernel or 
>> shorewall it has stopped working.  I only use pptp occasionally so I 
>> cannot be sure when it stopped.
>>
>> The firewall can accept pptp connections from the net and it is only 
>> the passthru that is broken.
>
> IIRC something changed with autoloading helper modules (don't know 
> exactly when): are the PPTP helper modules loaded?
>
> nf_nat_pptp.ko
> nf_conntrack_pptp.ko
>
> You would need nf_nat_pptp.ko for NAT-ing the PPTP protocol.

Oh, and lets not forget:

nf_nat_proto_gre.ko
nf_conntrack_proto_gre.ko


--
Rob

Re: PPTP passthrough

[Pascal Hambourg]

Le 04/05/2017 à 08:07, Rob Sterenborg (Lists) a écrit :
>
> IIRC something changed with autoloading helper modules (don't know
> exactly when): are the PPTP helper modules loaded?

AFAIK, helper modules were never autoloaded.
It is automatic helper assignment that was disabled by default, so a 
helper must be explicitly attached to a connection with the CT target.