ip_nat_pptp ICMP rejected failures
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=0and 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
Quoted 3 lines · Matt Domsch
Harald, thanks much for your efforts on the
ip_nat_pptphelper. 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
Signature · 5 lines
- Harald Welte <[email protected]> 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
Quoted 2 lines · Harald Welte
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.
Quoted 2 lines
thanks for the detailed bugreport, I'll try to analyze the problem once I'm back from http://workshop.netfilter.org/
Enjoy the workshop!
Quoted 3 lines
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=0There'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
Quoted 7 lines · Matt Domsch
Progress. To the raw table I added:
-A OUTPUT -p icmp --icmp-type protocol-unreachable --destinationPPTP_SERVER-j DROPNow what happens is that the LCP Configuration Requests and LCP Configuration Acks generated by the
PPTP_SERVERaren't getting NAT'd by the firewall coming back to my client, so LCP is never established. Removingip_nat_pptpresolves 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