All of lore.kernel.org
 help / color / mirror / Atom feed
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: Sat, 8 Oct 2005 00:05:42 -0500	[thread overview]
Message-ID: <20051008050541.GA20135@domsch.com> (raw)
In-Reply-To: <20051006035422.GA8836@domsch.com>

On Wed, Oct 05, 2005 at 10:54:22PM -0500, Matt Domsch wrote:
> 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.

Enabling debugging in the netfilter pptp and gre modules:

ip_conntrack_helper_pptp.c:conntrack_pptp_help: ctinfo = 2, skipping
ip_conntrack_helper_pptp.c:conntrack_pptp_help: no full PPTP header, can't track
ip_conntrack_helper_pptp.c:conntrack_pptp_help: no full PPTP header, can't track
ip_conntrack_helper_pptp.c:pptp_outbound_pkt: outbound control message START_SESSION_REQUEST
ip_conntrack_helper_pptp.c:conntrack_pptp_help: sstate: 0->3, cstate: 0->0
ip_conntrack_helper_pptp.c:pptp_inbound_pkt: inbound control message START_SESSION_REPLY
ip_conntrack_helper_pptp.c:conntrack_pptp_help: sstate: 3->4, cstate: 0->0
ip_conntrack_helper_pptp.c:conntrack_pptp_help: no full PPTP header, can't track
ip_conntrack_helper_pptp.c:pptp_outbound_pkt: outbound control message OUT_CALL_REQUEST
ip_conntrack_helper_pptp.c:pptp_outbound_pkt: OUT_CALL_REQUEST: short packet
ip_conntrack_helper_pptp.c:pptp_outbound_pkt: OUT_CALL_REQUEST, CID=0
ip_nat_helper_pptp.c:pptp_outbound_pkt: altering call id from 0x0000 to 0xb3a9
ip_conntrack_helper_pptp.c:conntrack_pptp_help: sstate: 4->4, cstate: 0->2
ip_conntrack_helper_pptp.c:pptp_inbound_pkt: inbound control message OUT_CALL_REPLY
ip_conntrack_helper_pptp.c:pptp_inbound_pkt: OUT_CALL_REPLY, CID=582F, PCID=B3A9
  (so far so good, these were forwarded by the firewall.  Then...)

ip_nat_helper_pptp.c:pptp_exp_gre: successfully registered expect
ip_nat_helper_pptp.c:pptp_exp_gre: successfully registered expect
ip_conntrack_proto_gre.c:ip_ct_gre_keymap_add: adding new entry d51597e0: PPTP_SERVER:0x582f -> FW_PUBLIC_IP:0xb3a9
ip_conntrack_proto_gre.c:ip_ct_gre_keymap_add: adding new entry d5159c80: CLIENT_IP:0x0 -> PPTP_SERVER:0x582f
ip_nat_helper_pptp.c:pptp_inbound_pkt: altering peer call id from 0xb3a9 to 0x0000
ip_conntrack_helper_pptp.c:conntrack_pptp_help: sstate: 4->4, cstate: 2->3
ip_conntrack_helper_pptp.c:conntrack_pptp_help: no full PPTP header, can't track
  (this is OK, this is just a TCP ACK)
ip_conntrack_proto_gre.c:gre_keymap_lookup: lookup src key 0x0 up key for CLIENT_IP:0xe054 -> PPTP_SERVER:0x582f
ip_conntrack_proto_gre.c:gre_new: : CLIENT_IP:0x0 -> PPTP_SERVER:0x582f
ip_conntrack_helper_pptp.c:pptp_expectfn: increasing timeouts
ip_nat_helper_pptp.c:pptp_nat_expected: we are PNS->PAC
ip_nat_helper_pptp.c:pptp_nat_expected: trying to unexpect other dir:
ip_nat_helper_pptp.c:pptp_nat_expected: tuple c044bda0: 47 PPTP_SERVER:22575 -> FW_PUBLIC_IP:45993
ip_nat_helper_pptp.c:pptp_nat_expected: success
ip_conntrack_proto_gre.c:gre_keymap_lookup: lookup src key 0x2f58 up key for PPTP_SERVER:0xe054 -> FW_PUBLIC_IP:0xb3a9
ip_conntrack_proto_gre.c:gre_new: : PPTP_SERVER:0x582f -> FW_PUBLIC_IP:0xb3a9
ip_conntrack_proto_gre.c:gre_keymap_lookup: lookup src key 0x2f58 up key for PPTP_SERVER:0xe054 -> FW_PUBLIC_IP:0xb3a9
ip_conntrack_proto_gre.c:gre_keymap_lookup: lookup src key 0x0 up key for CLIENT_IP:0xe054 -> PPTP_SERVER:0x582f
ip_conntrack_proto_gre.c:gre_keymap_lookup: lookup src key 0x2f58 up key for PPTP_SERVER:0xe054 -> FW_PUBLIC_IP:0xb3a9
ip_conntrack_proto_gre.c:gre_keymap_lookup: lookup src key 0x2f58 up key for PPTP_SERVER:0xe054 -> FW_PUBLIC_IP:0xb3a9
ip_conntrack_proto_gre.c:gre_keymap_lookup: lookup src key 0x0 up key for CLIENT_IP:0xe054 -> PPTP_SERVER:0x582f
ip_conntrack_proto_gre.c:gre_keymap_lookup: lookup src key 0x2f58 up key for PPTP_SERVER:0xe054 -> FW_PUBLIC_IP:0xb3a9
ip_conntrack_proto_gre.c:gre_keymap_lookup: lookup src key 0x2f58 up key for PPTP_SERVER:0xe054 -> FW_PUBLIC_IP:0xb3a9
ip_conntrack_proto_gre.c:gre_keymap_lookup: lookup src key 0x0 up key for CLIENT_IP:0xe054 -> PPTP_SERVER:0x582f
ip_conntrack_proto_gre.c:gre_keymap_lookup: lookup src key 0x2f58 up key for PPTP_SERVER:0xe054 -> FW_PUBLIC_IP:0xb3a9
ip_conntrack_proto_gre.c:gre_keymap_lookup: lookup src key 0x2f58 up key for PPTP_SERVER:0xe054 -> FW_PUBLIC_IP:0xb3a9
ip_conntrack_proto_gre.c:gre_keymap_lookup: lookup src key 0x0 up key for CLIENT_IP:0xe054 -> PPTP_SERVER:0x582f
ip_conntrack_proto_gre.c:gre_keymap_lookup: lookup src key 0x2f58 up key for PPTP_SERVER:0xe054 -> FW_PUBLIC_IP:0xb3a9
ip_conntrack_helper_pptp.c:pptp_outbound_pkt: outbound control message CALL_CLEAR_REQUEST
ip_nat_helper_pptp.c:pptp_outbound_pkt: altering call id from 0x0000 to 0xb3a9

and now we're dead in the water.

Thanks,
Matt


      reply	other threads:[~2005-10-08  5:05 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
2005-10-08  5:05     ` Matt Domsch [this message]

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=20051008050541.GA20135@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.