From: Matt Domsch <matt@domsch.com>
To: Harald Welte <laforge@netfilter.org>, netfilter@lists.netfilter.org
Subject: Re: ip_nat_pptp ICMP rejected failures
Date: Wed, 5 Oct 2005 22:54:22 -0500 [thread overview]
Message-ID: <20051006035422.GA8836@domsch.com> (raw)
In-Reply-To: <20051005154453.GC4184@rama>
[-- Attachment #1: Type: text/plain, Size: 5466 bytes --]
On Wed, Oct 05, 2005 at 05:44:53PM +0200, Harald Welte wrote:
> On Wed, Oct 05, 2005 at 10:13:09AM -0500, Matt Domsch wrote:
> there have been patches for lots of 2.4 and 2.6 releases, though.
Indeed, I've been lazy in this respect, no disrespect intended.
> thanks for the detailed bugreport, I'll try to analyze the problem once
> I'm back from http://workshop.netfilter.org/
Enjoy the workshop!
> Please try to explicitly add a drop rule for the ICMP packets and see
> whether it works then. Sounds strange, but I have my reasons for asking
> ;)
Progress. To the raw table I added:
-A OUTPUT -p icmp --icmp-type protocol-unreachable --destination PPTP_SERVER -j DROP
Now what happens is that the LCP Configuration Requests and LCP
Configuration Acks generated by the PPTP_SERVER aren't getting NAT'd
by the firewall coming back to my client, so LCP is never
established. Removing ip_nat_pptp resolves this of course.
No. Time Source Destination Protocol Info
47 1.029527 CLIENT_IP PPTP_SERVER TCP 4668 > 1723 [SYN] Seq=0 Ack=0 Win=64512 Len=0 MSS=1460
48 1.029729 FW_PUBLIC_IP PPTP_SERVER TCP 4668 > 1723 [SYN] Seq=0 Ack=0 Win=64512 Len=0 MSS=1460
49 1.056471 PPTP_SERVER FW_PUBLIC_IP TCP 1723 > 4668 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460
50 1.056586 PPTP_SERVER CLIENT_IP TCP 1723 > 4668 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460
51 1.071807 CLIENT_IP PPTP_SERVER PPTP Start-Control-Connection-Request
52 1.071899 FW_PUBLIC_IP PPTP_SERVER PPTP Start-Control-Connection-Request
53 1.096896 PPTP_SERVER FW_PUBLIC_IP PPTP Start-Control-Connection-Reply
54 1.096993 PPTP_SERVER CLIENT_IP PPTP Start-Control-Connection-Reply
55 1.108357 CLIENT_IP PPTP_SERVER PPTP Outgoing-Call-Request
56 1.108461 FW_PUBLIC_IP PPTP_SERVER PPTP Outgoing-Call-Request
57 1.133729 PPTP_SERVER FW_PUBLIC_IP PPTP Outgoing-Call-Reply
58 1.133875 PPTP_SERVER CLIENT_IP PPTP Outgoing-Call-Reply
59 1.137014 CLIENT_IP PPTP_SERVER PPTP Set-Link-Info
60 1.137101 FW_PUBLIC_IP PPTP_SERVER PPTP Set-Link-Info
61 1.149890 CLIENT_IP PPTP_SERVER PPP LCP Configuration Request
62 1.150004 FW_PUBLIC_IP PPTP_SERVER PPP LCP Configuration Request
63 1.174587 PPTP_SERVER FW_PUBLIC_IP PPP LCP Configuration Request
====== The previous packet should be NAT'd here, but it's not.
64 1.174765 PPTP_SERVER FW_PUBLIC_IP PPP LCP Configuration Ack
====== The previous packet should be NAT'd here, but it's not.
71 1.335423 PPTP_SERVER FW_PUBLIC_IP TCP 1723 > 4668 [ACK] Seq=189 Ack=349 Win=17172 Len=0
72 1.335582 PPTP_SERVER CLIENT_IP TCP 1723 > 4668 [ACK] Seq=189 Ack=349 Win=17172 Len=0
96 2.319976 PPTP_SERVER FW_PUBLIC_IP PPP LCP Configuration Request
====== The previous packet should be NAT'd here, but it's not.
125 3.136456 CLIENT_IP PPTP_SERVER PPP LCP Configuration Request
126 3.136592 FW_PUBLIC_IP PPTP_SERVER PPP LCP Configuration Request
127 3.160169 PPTP_SERVER FW_PUBLIC_IP PPP LCP Configuration Ack
====== The previous packet should be NAT'd here, but it's not.
181 5.319708 PPTP_SERVER FW_PUBLIC_IP PPP LCP Configuration Request
====== The previous packet should be NAT'd here, but it's not.
213 6.133984 CLIENT_IP PPTP_SERVER PPP LCP Configuration Request
214 6.134116 FW_PUBLIC_IP PPTP_SERVER PPP LCP Configuration Request
215 6.159191 PPTP_SERVER FW_PUBLIC_IP PPP LCP Configuration Ack
====== The previous packet should be NAT'd here, but it's not.
308 9.319669 PPTP_SERVER FW_PUBLIC_IP PPP LCP Configuration Request
====== The previous packet should be NAT'd here, but it's not.
340 10.144477 CLIENT_IP PPTP_SERVER PPP LCP Configuration Request
341 10.144617 FW_PUBLIC_IP PPTP_SERVER PPP LCP Configuration Request
342 10.167478 PPTP_SERVER FW_PUBLIC_IP PPP LCP Configuration Ack
427 13.061012 CLIENT_IP PPTP_SERVER PPTP Set-Link-Info
428 13.061137 FW_PUBLIC_IP PPTP_SERVER PPTP Set-Link-Info
429 13.071593 CLIENT_IP PPTP_SERVER PPP LCP Termination Request
430 13.071680 FW_PUBLIC_IP PPTP_SERVER PPP LCP Termination Request
431 13.095415 PPTP_SERVER FW_PUBLIC_IP PPP LCP Termination Ack
435 13.258806 PPTP_SERVER FW_PUBLIC_IP TCP 1723 > 4668 [ACK] Seq=189 Ack=373 Win=17148 Len=0
436 13.258922 PPTP_SERVER CLIENT_IP TCP 1723 > 4668 [ACK] Seq=189 Ack=373 Win=17148 Len=0
There's no apparent difference between the packets that are NATd
without ip_nat_pptp and the packets that aren't when using ip_nat_pptp.
Thanks,
Matt
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2005-10-06 3:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-05 15:13 ip_nat_pptp ICMP rejected failures Matt Domsch
2005-10-05 15:44 ` Harald Welte
2005-10-06 3:54 ` Matt Domsch [this message]
2005-10-08 5:05 ` Matt Domsch
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20051006035422.GA8836@domsch.com \
--to=matt@domsch.com \
--cc=laforge@netfilter.org \
--cc=netfilter@lists.netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox