[Closed] No NAT, pass-through PPTP (GRE)

I use VyOS 1.1.7 as a router with BGP and VRRP only. No NAT. No firewall.

There’s Windows Server 2008 R2 behind VyOS. I need to establish client PPTP session from this server to another point. Link is established but user checking is failed with error 734. There’s “Recv timeout event received for portid=24,Id=0,Protocol=c021,fAuth=0” message in ppp.log.

With other network this server connect to this point successfully.

I’ve tried to use zone based firewall with direct acceptance of GRE protocol in both directions. It doesn’t help.

What should i do to solve the problem?

It seems that VyOS doesn’t pass packets with Configure-Reject operation code from external PPTP server to internal PPTP client.
Wireshark shows missing of such packets.

Since no firewall is involved , prime suspect is pptp helper , disable it:
set system conntrack modules pptp disable

Brings back memories: Years ago I spent time comparing wireshark traces (ethereal in those days) , and only by comparing ttl values and packets sizes, I noticed some helper rewrote my h.323 packets

Thanks for reply.

I’ve tried “set system conntrack modules pptp disable” with and without “set system conntrack modules gre disable”.
I’ve tried “set system conntrack tcp loose disable”.

Together and separately.

No result. :frowning:

I received IP packet data from uplink router. This data contains packets with Configure-Reject operation code from PPTP server to PPTP client.
VyOS’s tshark doesn’t capture such packets on ethernet interfaces. Not on interface to uplink, nor on interface to PPTP client.

Who do process traffic before tshark captures it on uplink interface?

Unforunately, my Windows Server with PPTP client shows itself as doubtful source. I’ve done many changes including moving VyOS VM to another host (where VM was planned to place), so I don’t know what change solved problem. But it’s solved. PPTP clients (not from my test server) connect to PPTP server successfully.
So this thread can be marked as closed.

Closing as per your request.
some times problem is not in network :slight_smile: