* ip_nat_pptp ICMP rejected failures
@ 2005-10-05 15:13 Matt Domsch
2005-10-05 15:44 ` Harald Welte
0 siblings, 1 reply; 4+ messages in thread
From: Matt Domsch @ 2005-10-05 15:13 UTC (permalink / raw)
To: Harald Welte; +Cc: netfilter
Harald, thanks much for your efforts on the ip_nat_pptp helper. I've
been using a 2.2 kernel on my firewall for years simply because it had
this functionality.
I have this problem with 2.6.14-rc3. With ip_nat_pptp loaded,
through a NAT, I get this behavior:
No. Time Source Destination Protocol Info
1 0.000000 NAT-CLIENT PPTP-SERVER TCP 3347 > 1723 [SYN] Seq=0 Ack=0 Win=64512 Len=0 MSS=1460
2 0.000237 FW-PUBLIC-IP PPTP-SERVER TCP 3347 > 1723 [SYN] Seq=0 Ack=0 Win=64512 Len=0 MSS=1460
3 0.026441 PPTP-SERVER FW-PUBLIC-IP TCP 1723 > 3347 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460
4 0.026574 PPTP-SERVER NAT-CLIENT TCP 1723 > 3347 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460
5 0.027555 NAT-CLIENT PPTP-SERVER PPTP Start-Control-Connection-Request
6 0.027652 FW-PUBLIC-IP PPTP-SERVER PPTP Start-Control-Connection-Request
7 0.051931 PPTP-SERVER FW-PUBLIC-IP PPTP Start-Control-Connection-Reply
8 0.052072 PPTP-SERVER NAT-CLIENT PPTP Start-Control-Connection-Reply
9 0.063546 NAT-CLIENT PPTP-SERVER PPTP Outgoing-Call-Request
10 0.063654 FW-PUBLIC-IP PPTP-SERVER PPTP Outgoing-Call-Request
11 0.090422 PPTP-SERVER FW-PUBLIC-IP PPTP Outgoing-Call-Reply
12 0.090565 PPTP-SERVER NAT-CLIENT PPTP Outgoing-Call-Reply
13 0.096314 NAT-CLIENT PPTP-SERVER PPTP Set-Link-Info
14 0.096397 FW-PUBLIC-IP PPTP-SERVER PPTP Set-Link-Info
15 0.096428 NAT-CLIENT PPTP-SERVER PPP LCP Configuration Request
16 0.096527 FW-PUBLIC-IP PPTP-SERVER PPP LCP Configuration Request
17 0.126681 PPTP-SERVER FW-PUBLIC-IP PPP LCP Configuration Request
18 0.127033 FW-PUBLIC-IP PPTP-SERVER ICMP Destination unreachable (Protocol unreachable)
19 0.127074 PPTP-SERVER FW-PUBLIC-IP PPP LCP Configuration Ack
20 0.127177 FW-PUBLIC-IP PPTP-SERVER ICMP Destination unreachable (Protocol unreachable)
21 0.312610 PPTP-SERVER FW-PUBLIC-IP TCP 1723 > 3347 [ACK] Seq=189 Ack=349 Win=17172 Len=0
22 0.312723 PPTP-SERVER NAT-CLIENT TCP 1723 > 3347 [ACK] Seq=189 Ack=349 Win=17172 Len=0
23 1.937329 PPTP-SERVER FW-PUBLIC-IP PPP LCP Configuration Request
24 1.937557 FW-PUBLIC-IP PPTP-SERVER ICMP Destination unreachable (Protocol unreachable)
25 2.098675 NAT-CLIENT PPTP-SERVER PPP LCP Configuration Request
26 2.098788 FW-PUBLIC-IP PPTP-SERVER PPP LCP Configuration Request
27 2.122375 PPTP-SERVER FW-PUBLIC-IP PPP LCP Configuration Ack
28 2.122580 FW-PUBLIC-IP PPTP-SERVER ICMP Destination unreachable (Protocol unreachable)
29 4.937426 PPTP-SERVER FW-PUBLIC-IP PPP LCP Configuration Request
30 4.937632 FW-PUBLIC-IP PPTP-SERVER ICMP Destination unreachable (Protocol unreachable)
31 5.108775 NAT-CLIENT PPTP-SERVER PPP LCP Configuration Request
32 5.108878 FW-PUBLIC-IP PPTP-SERVER PPP LCP Configuration Request
33 5.133111 PPTP-SERVER FW-PUBLIC-IP PPP LCP Configuration Ack
34 5.133317 FW-PUBLIC-IP PPTP-SERVER ICMP Destination unreachable (Protocol unreachable)
35 7.549272 NAT-CLIENT PPTP-SERVER PPTP Set-Link-Info
36 7.549405 FW-PUBLIC-IP PPTP-SERVER PPTP Set-Link-Info
37 7.549444 NAT-CLIENT PPTP-SERVER PPP LCP Termination Request
38 7.549510 FW-PUBLIC-IP PPTP-SERVER PPP LCP Termination Request
39 7.572922 PPTP-SERVER FW-PUBLIC-IP PPP LCP Termination Ack
40 7.573142 FW-PUBLIC-IP PPTP-SERVER ICMP Destination unreachable (Protocol unreachable)
41 7.748978 PPTP-SERVER FW-PUBLIC-IP TCP 1723 > 3347 [ACK] Seq=189 Ack=373 Win=17148 Len=0
42 7.749092 PPTP-SERVER NAT-CLIENT TCP 1723 > 3347 [ACK] Seq=189 Ack=373 Win=17148 Len=0
and no PPP authentication ever succeeds.
If I don't have ip_nat_pptp and ip_conntrack_pptp loaded, I don't get
the ICMP messages, and authentication succeeds, though I can only have
on PPTP session between any of my clients and the server.
My iptables firewall rules, generated by a Fedora Core 4 system, look like:
# Firewall configuration written by system-config-securitylevel
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -i eth1 -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
-A RH-Firewall-1-INPUT -p 50 -j ACCEPT
-A RH-Firewall-1-INPUT -p 51 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m udp --dport 53 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 53 -j ACCEPT
-A RH-Firewall-1-INPUT --protocol gre -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT
*mangle
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A PREROUTING -i eth1 -j MARK --set-mark 0x9
COMMIT
*nat
:PREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -m mark --mark 0x9 -j MASQUERADE
COMMIT
though I've tried both with and without the REJECT rule.
I'd appreciate any advice you can provide.
Thanks,
Matt
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: ip_nat_pptp ICMP rejected failures
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
0 siblings, 1 reply; 4+ messages in thread
From: Harald Welte @ 2005-10-05 15:44 UTC (permalink / raw)
To: Matt Domsch; +Cc: netfilter
[-- Attachment #1: Type: text/plain, Size: 956 bytes --]
On Wed, Oct 05, 2005 at 10:13:09AM -0500, Matt Domsch wrote:
> Harald, thanks much for your efforts on the ip_nat_pptp helper. I've
> been using a 2.2 kernel on my firewall for years simply because it had
> this functionality.
there have been patches for lots of 2.4 and 2.6 releases, though.
thanks for the detailed bugreport, I'll try to analyze the problem once
I'm back from http://workshop.netfilter.org/
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
;)
Thanks
--
- Harald Welte <laforge@netfilter.org> http://netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: ip_nat_pptp ICMP rejected failures
2005-10-05 15:44 ` Harald Welte
@ 2005-10-06 3:54 ` Matt Domsch
2005-10-08 5:05 ` Matt Domsch
0 siblings, 1 reply; 4+ messages in thread
From: Matt Domsch @ 2005-10-06 3:54 UTC (permalink / raw)
To: Harald Welte, netfilter
[-- 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 --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: ip_nat_pptp ICMP rejected failures
2005-10-06 3:54 ` Matt Domsch
@ 2005-10-08 5:05 ` Matt Domsch
0 siblings, 0 replies; 4+ messages in thread
From: Matt Domsch @ 2005-10-08 5:05 UTC (permalink / raw)
To: Harald Welte, netfilter
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2005-10-08 5:05 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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 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.