Hello,
I have some ICMP packets with the content (Destination unreachable) / (Port unreachable) when I use CREATE in NATFW. Could you suggest if it is a problem of the implementation or configuration?
The scenario is
DS NI NF NR 10.1.1.5 10.1.1.7 / 10.1.2.7 10.1.2.11 . . . . . . .---------CREATE---------->. . . . . . .---------CREATE---------->. . . . . .<-------RESPONSE----------. .<-------RESPONSE----------. . . . .
by using in the NI: ./nsis-natfw --create -s 10.1.1.5 -d 10.1.2.11 --sport 5004 --dport 5019
The flow above is Ok, but I have some ICMP packets with the content (Destination unreachable) / (Port unreachable). Frames 3, 12 and 14 below.
Config.ini are as follows
{ NI Node 10.1.1.5
IPv4[0].addr = 10.1.1.5 IPv4[0].net = 0.0.0.0 IPv4[0].mask = 0 IPv4[0].natfw.useAsExternalAddress = yes IPv4[0].natfw.isPrivateNet = yes natfw.isNAT = no natfw.isFW = no }
{ NF Node 10.1.1.7 / 10.1.2.7
IPv4[0].addr = 10.1.1.7 IPv4[0].net = 10.1.1.0 IPv4[0].mask = 24 IPv4[0].natfw.useAsExternalAddress = no IPv4[0].natfw.isPrivateNet = yes
IPv4[1].addr = 10.1.2.7 IPv4[1].net = 10.1.2.0 IPv4[1].mask = 24 IPv4[1].natfw.useAsExternalAddress = yes IPv4[1].natfw.isPrivateNet = no natfw.isNAT = no natfw.isFW = yes }
{ NR Node 10.1.2.11
IPv4[0].addr = 10.1.2.11 IPv4[0].net = 0.0.0.0 IPv4[0].mask = 0 IPv4[0].natfw.useAsExternalAddress = yes IPv4[0].natfw.isPrivateNet = no natfw.isNAT = no natfw.isFW = no }
Ethereal dump:
Frame 1 (190 bytes on wire, 190 bytes captured) Protocols in frame: eth:ip:udp:gist Internet Protocol, Src Addr: 10.1.1.5 (10.1.1.5), Dst Addr: 10.1.2.11 (10.1.2.11) User Datagram Protocol, Src Port: 33113 (33113), Dst Port: 4 (4) General Internet Signaling Transport Signaling Application ID: NAT/FW NSLP (3) Type: Query (0)
Frame 2 (226 bytes on wire, 226 bytes captured) Protocols in frame: eth:ip:udp:gist Internet Protocol, Src Addr: 10.1.1.7 (10.1.1.7), Dst Addr: 10.1.1.5 (10.1.1.5) User Datagram Protocol, Src Port: 33086 (33086), Dst Port: 4 (4) General Internet Signaling Transport Signaling Application ID: NAT/FW NSLP (3) Type: response (1)
Frame 3 (254 bytes on wire, 254 bytes captured) Protocols in frame: eth:ip:icmp:ip:udp:gist Internet Protocol, Src Addr: 10.1.1.5 (10.1.1.5), Dst Addr: 10.1.1.7 (10.1.1.7) Internet Control Message Protocol Type: 3 (Destination unreachable) Code: 3 (Port unreachable) Checksum: 0x13dc (correct) Internet Protocol, Src Addr: 10.1.1.7 (10.1.1.7), Dst Addr: 10.1.1.5 (10.1.1.5) User Datagram Protocol, Src Port: 33086 (33086), Dst Port: 4 (4) General Internet Signaling Transport Signaling Application ID: NAT/FW NSLP (3) Type: response (1)
Frame 7 (182 bytes on wire, 182 bytes captured) Protocols in frame: eth:ip:tcp:gist Internet Protocol, Src Addr: 10.1.1.5 (10.1.1.5), Dst Addr: 10.1.1.7 (10.1.1.7) Transmission Control Protocol, Src Port: 42338 (42338), Dst Port: 32000 (32000), Seq: 1, Ack: 1, Len: 116 General Internet Signaling Transport Signaling Application ID: NAT/FW NSLP (3) Type: Confirm (2)
Frame 9 (206 bytes on wire, 206 bytes captured) Protocols in frame: eth:ip:tcp:gist Internet Protocol, Src Addr: 10.1.1.5 (10.1.1.5), Dst Addr: 10.1.1.7 (10.1.1.7) Transmission Control Protocol, Src Port: 42338 (42338), Dst Port: 32000 (32000), Seq: 117, Ack: 1, Len: 140 General Internet Signaling Transport NAT/FW NSLP (NSIS Signaling Layer Protocol) Message Type: CREATE (0x01)
Frame 11 (190 bytes on wire, 190 bytes captured) Protocols in frame: eth:ip:udp:gist Internet Protocol, Src Addr: 10.1.2.7 (10.1.2.7), Dst Addr: 10.1.2.11 (10.1.2.11) User Datagram Protocol, Src Port: 33086 (33086), Dst Port: 4 (4) General Internet Signaling Transport Signaling Application ID: NAT/FW NSLP (3) Type: Query (0)
Frame 12 (218 bytes on wire, 218 bytes captured) Protocols in frame: eth:ip:icmp:ip:udp:gist Internet Protocol, Src Addr: 10.1.2.11 (10.1.2.11), Dst Addr: 10.1.2.7 (10.1.2.7) Internet Control Message Protocol Type: 3 (Destination unreachable) Code: 3 (Port unreachable) Internet Protocol, Src Addr: 10.1.2.7 (10.1.2.7), Dst Addr: 10.1.2.11 (10.1.2.11) User Datagram Protocol, Src Port: 33086 (33086), Dst Port: 4 (4) General Internet Signaling Transport Signaling Application ID: NAT/FW NSLP (3) Type: Query (0)
Frame 13 (226 bytes on wire, 226 bytes captured) Protocols in frame: eth:ip:udp:gist Internet Protocol, Src Addr: 10.1.2.11 (10.1.2.11), Dst Addr: 10.1.2.7 (10.1.2.7) User Datagram Protocol, Src Port: 33062 (33062), Dst Port: 4 (4) General Internet Signaling Transport Signaling Application ID: NAT/FW NSLP (3) Type: Response (1)
Frame 14 (254 bytes on wire, 254 bytes captured) Protocols in frame: eth:ip:icmp:ip:udp:gist Internet Protocol, Src Addr: 10.1.2.7 (10.1.2.7), Dst Addr: 10.1.2.11 (10.1.2.11) Internet Control Message Protocol Type: 3 (Destination unreachable) Code: 3 (Port unreachable) Internet Protocol, Src Addr: 10.1.2.11 (10.1.2.11), Dst Addr: 10.1.2.7 (10.1.2.7) User Datagram Protocol, Src Port: 33062 (33062), Dst Port: 4 (4) General Internet Signaling Transport Signaling Application ID: NAT/FW NSLP (3) Type: Response (1)
Frame 18 (182 bytes on wire, 182 bytes captured) Protocols in frame: eth:ip:tcp:gist Internet Protocol, Src Addr: 10.1.2.7 (10.1.2.7), Dst Addr: 10.1.2.11 (10.1.2.11) Transmission Control Protocol, Src Port: 34969 (34969), Dst Port: 32000 (32000), Seq: 1, Ack: 1, Len: 116 General Internet Signaling Transport
Frame 20 (206 bytes on wire, 206 bytes captured) Protocols in frame: eth:ip:tcp:gist Internet Protocol, Src Addr: 10.1.2.7 (10.1.2.7), Dst Addr: 10.1.2.11 (10.1.2.11) Transmission Control Protocol, Src Port: 34969 (34969), Dst Port: 32000 (32000), Seq: 117, Ack: 1, Len: 140 General Internet Signaling Transport Signaling Application ID: NAT/FW NSLP (3) Type: Data (3) NAT/FW NSLP (NSIS Signaling Layer Protocol)
Frame 22 (182 bytes on wire, 182 bytes captured) Protocols in frame: eth:ip:tcp:gist Internet Protocol, Src Addr: 10.1.2.11 (10.1.2.11), Dst Addr: 10.1.2.7 (10.1.2.7) Transmission Control Protocol, Src Port: 32000 (32000), Dst Port: 34969 (34969), Seq: 1, Ack: 257, Len: 116 General Internet Signaling Transport Signaling Application ID: NAT/FW NSLP (3) Type: Data (3) NAT/FW NSLP (NSIS Signaling Layer Protocol)
Frame 24 (182 bytes on wire, 182 bytes captured) Protocols in frame: eth:ip:tcp:gist Internet Protocol, Src Addr: 10.1.1.7 (10.1.1.7), Dst Addr: 10.1.1.5 (10.1.1.5) Transmission Control Protocol, Src Port: 32000 (32000), Dst Port: 42338 (42338), Seq: 1, Ack: 257, Len: 116 General Internet Signaling Transport NAT/FW NSLP (NSIS Signaling Layer Protocol) Message Type: RESPONSE (0x04)
Regards,
Sergio
Hi Sergio,
these ICMP packets are triggered by your TCP/IP stack, because there is no process listening on these ports.
There is nothing wrong here, this is absolutely expected the way how GIST intercepts packets (BPF, raw sockets).
I have not looked into your dumps in detail, but I assume that this problem is not related to a particular NSLP, but GIST (try Ping NSLP).
Right now we don't bother about this or filter it in a fw outbound chain (ugly!). Finally, we need sth. clean here, of course. Suggestions?
Henning
sergiole@tml.hut.fi wrote:
Hello,
I have some ICMP packets with the content (Destination unreachable) / (Port unreachable) when I use CREATE in NATFW. Could you suggest if it is a problem of the implementation or configuration?
The scenario is
DS NI NF NR 10.1.1.5 10.1.1.7 / 10.1.2.7 10.1.2.11 . . . . . . .---------CREATE---------->. . . . . . .---------CREATE---------->. . . . . .<-------RESPONSE----------. .<-------RESPONSE----------. . . . .
by using in the NI: ./nsis-natfw --create -s 10.1.1.5 -d 10.1.2.11 --sport 5004 --dport 5019
The flow above is Ok, but I have some ICMP packets with the content (Destination unreachable) / (Port unreachable). Frames 3, 12 and 14 below.
Config.ini are as follows
{ NI Node 10.1.1.5
IPv4[0].addr = 10.1.1.5 IPv4[0].net = 0.0.0.0 IPv4[0].mask = 0 IPv4[0].natfw.useAsExternalAddress = yes IPv4[0].natfw.isPrivateNet = yes natfw.isNAT = no natfw.isFW = no }
{ NF Node 10.1.1.7 / 10.1.2.7
IPv4[0].addr = 10.1.1.7 IPv4[0].net = 10.1.1.0 IPv4[0].mask = 24 IPv4[0].natfw.useAsExternalAddress = no IPv4[0].natfw.isPrivateNet = yes
IPv4[1].addr = 10.1.2.7 IPv4[1].net = 10.1.2.0 IPv4[1].mask = 24 IPv4[1].natfw.useAsExternalAddress = yes IPv4[1].natfw.isPrivateNet = no natfw.isNAT = no natfw.isFW = yes }
{ NR Node 10.1.2.11
IPv4[0].addr = 10.1.2.11 IPv4[0].net = 0.0.0.0 IPv4[0].mask = 0 IPv4[0].natfw.useAsExternalAddress = yes IPv4[0].natfw.isPrivateNet = no natfw.isNAT = no natfw.isFW = no }
Ethereal dump:
Frame 1 (190 bytes on wire, 190 bytes captured) Protocols in frame: eth:ip:udp:gist Internet Protocol, Src Addr: 10.1.1.5 (10.1.1.5), Dst Addr: 10.1.2.11 (10.1.2.11) User Datagram Protocol, Src Port: 33113 (33113), Dst Port: 4 (4) General Internet Signaling Transport Signaling Application ID: NAT/FW NSLP (3) Type: Query (0)
Frame 2 (226 bytes on wire, 226 bytes captured) Protocols in frame: eth:ip:udp:gist Internet Protocol, Src Addr: 10.1.1.7 (10.1.1.7), Dst Addr: 10.1.1.5 (10.1.1.5) User Datagram Protocol, Src Port: 33086 (33086), Dst Port: 4 (4) General Internet Signaling Transport Signaling Application ID: NAT/FW NSLP (3) Type: response (1)
Frame 3 (254 bytes on wire, 254 bytes captured) Protocols in frame: eth:ip:icmp:ip:udp:gist Internet Protocol, Src Addr: 10.1.1.5 (10.1.1.5), Dst Addr: 10.1.1.7 (10.1.1.7) Internet Control Message Protocol Type: 3 (Destination unreachable) Code: 3 (Port unreachable) Checksum: 0x13dc (correct) Internet Protocol, Src Addr: 10.1.1.7 (10.1.1.7), Dst Addr: 10.1.1.5 (10.1.1.5) User Datagram Protocol, Src Port: 33086 (33086), Dst Port: 4 (4) General Internet Signaling Transport Signaling Application ID: NAT/FW NSLP (3) Type: response (1)
Frame 7 (182 bytes on wire, 182 bytes captured) Protocols in frame: eth:ip:tcp:gist Internet Protocol, Src Addr: 10.1.1.5 (10.1.1.5), Dst Addr: 10.1.1.7 (10.1.1.7) Transmission Control Protocol, Src Port: 42338 (42338), Dst Port: 32000 (32000), Seq: 1, Ack: 1, Len: 116 General Internet Signaling Transport Signaling Application ID: NAT/FW NSLP (3) Type: Confirm (2)
Frame 9 (206 bytes on wire, 206 bytes captured) Protocols in frame: eth:ip:tcp:gist Internet Protocol, Src Addr: 10.1.1.5 (10.1.1.5), Dst Addr: 10.1.1.7 (10.1.1.7) Transmission Control Protocol, Src Port: 42338 (42338), Dst Port: 32000 (32000), Seq: 117, Ack: 1, Len: 140 General Internet Signaling Transport NAT/FW NSLP (NSIS Signaling Layer Protocol) Message Type: CREATE (0x01)
Frame 11 (190 bytes on wire, 190 bytes captured) Protocols in frame: eth:ip:udp:gist Internet Protocol, Src Addr: 10.1.2.7 (10.1.2.7), Dst Addr: 10.1.2.11 (10.1.2.11) User Datagram Protocol, Src Port: 33086 (33086), Dst Port: 4 (4) General Internet Signaling Transport Signaling Application ID: NAT/FW NSLP (3) Type: Query (0)
Frame 12 (218 bytes on wire, 218 bytes captured) Protocols in frame: eth:ip:icmp:ip:udp:gist Internet Protocol, Src Addr: 10.1.2.11 (10.1.2.11), Dst Addr: 10.1.2.7 (10.1.2.7) Internet Control Message Protocol Type: 3 (Destination unreachable) Code: 3 (Port unreachable) Internet Protocol, Src Addr: 10.1.2.7 (10.1.2.7), Dst Addr: 10.1.2.11 (10.1.2.11) User Datagram Protocol, Src Port: 33086 (33086), Dst Port: 4 (4) General Internet Signaling Transport Signaling Application ID: NAT/FW NSLP (3) Type: Query (0)
Frame 13 (226 bytes on wire, 226 bytes captured) Protocols in frame: eth:ip:udp:gist Internet Protocol, Src Addr: 10.1.2.11 (10.1.2.11), Dst Addr: 10.1.2.7 (10.1.2.7) User Datagram Protocol, Src Port: 33062 (33062), Dst Port: 4 (4) General Internet Signaling Transport Signaling Application ID: NAT/FW NSLP (3) Type: Response (1)
Frame 14 (254 bytes on wire, 254 bytes captured) Protocols in frame: eth:ip:icmp:ip:udp:gist Internet Protocol, Src Addr: 10.1.2.7 (10.1.2.7), Dst Addr: 10.1.2.11 (10.1.2.11) Internet Control Message Protocol Type: 3 (Destination unreachable) Code: 3 (Port unreachable) Internet Protocol, Src Addr: 10.1.2.11 (10.1.2.11), Dst Addr: 10.1.2.7 (10.1.2.7) User Datagram Protocol, Src Port: 33062 (33062), Dst Port: 4 (4) General Internet Signaling Transport Signaling Application ID: NAT/FW NSLP (3) Type: Response (1)
Frame 18 (182 bytes on wire, 182 bytes captured) Protocols in frame: eth:ip:tcp:gist Internet Protocol, Src Addr: 10.1.2.7 (10.1.2.7), Dst Addr: 10.1.2.11 (10.1.2.11) Transmission Control Protocol, Src Port: 34969 (34969), Dst Port: 32000 (32000), Seq: 1, Ack: 1, Len: 116 General Internet Signaling Transport
Frame 20 (206 bytes on wire, 206 bytes captured) Protocols in frame: eth:ip:tcp:gist Internet Protocol, Src Addr: 10.1.2.7 (10.1.2.7), Dst Addr: 10.1.2.11 (10.1.2.11) Transmission Control Protocol, Src Port: 34969 (34969), Dst Port: 32000 (32000), Seq: 117, Ack: 1, Len: 140 General Internet Signaling Transport Signaling Application ID: NAT/FW NSLP (3) Type: Data (3) NAT/FW NSLP (NSIS Signaling Layer Protocol)
Frame 22 (182 bytes on wire, 182 bytes captured) Protocols in frame: eth:ip:tcp:gist Internet Protocol, Src Addr: 10.1.2.11 (10.1.2.11), Dst Addr: 10.1.2.7 (10.1.2.7) Transmission Control Protocol, Src Port: 32000 (32000), Dst Port: 34969 (34969), Seq: 1, Ack: 257, Len: 116 General Internet Signaling Transport Signaling Application ID: NAT/FW NSLP (3) Type: Data (3) NAT/FW NSLP (NSIS Signaling Layer Protocol)
Frame 24 (182 bytes on wire, 182 bytes captured) Protocols in frame: eth:ip:tcp:gist Internet Protocol, Src Addr: 10.1.1.7 (10.1.1.7), Dst Addr: 10.1.1.5 (10.1.1.5) Transmission Control Protocol, Src Port: 32000 (32000), Dst Port: 42338 (42338), Seq: 1, Ack: 257, Len: 116 General Internet Signaling Transport NAT/FW NSLP (NSIS Signaling Layer Protocol) Message Type: RESPONSE (0x04)
Regards,
Sergio
Nsis_Imp mailing list Nsis_Imp@informatik.uni-goettingen.de https://user.informatik.uni-goettingen.de/mailman/listinfo/nsis_imp
Henning Peters schrieb:
Hi Sergio,
these ICMP packets are triggered by your TCP/IP stack, because there is no process listening on these ports.
There is nothing wrong here, this is absolutely expected the way how GIST intercepts packets (BPF, raw sockets).
I have not looked into your dumps in detail, but I assume that this problem is not related to a particular NSLP, but GIST (try Ping NSLP).
Right now we don't bother about this or filter it in a fw outbound chain (ugly!). Finally, we need sth. clean here, of course. Suggestions?
IMHO the one and only clean solution is "fixing" the kernel.
Christian Dickmann
1) Is this a protocol violation or a bug (overlooked feature)?
2) When should the kernel suppress the generation of such a message (I suppose it is not sufficient that there is an open raw socket)?
3) Configuration via setsockopt?
Henning
Christian Dickmann wrote:
Henning Peters schrieb:
Hi Sergio,
these ICMP packets are triggered by your TCP/IP stack, because there is no process listening on these ports.
There is nothing wrong here, this is absolutely expected the way how GIST intercepts packets (BPF, raw sockets).
I have not looked into your dumps in detail, but I assume that this problem is not related to a particular NSLP, but GIST (try Ping NSLP).
Right now we don't bother about this or filter it in a fw outbound chain (ugly!). Finally, we need sth. clean here, of course. Suggestions?
IMHO the one and only clean solution is "fixing" the kernel.
Christian Dickmann
Hi Henning,
- Is this a protocol violation or a bug (overlooked feature)?
Regarding which protocol? With regard to GIST this is a "bug". ICMP errors should only be sent when there is really no GIST on the node.
- When should the kernel suppress the generation of such a message (I
suppose it is not sufficient that there is an open raw socket)?
Good question. I am not completely sure in which situations the ICMP errors are sent. IIRC we receive GIST messages using the UDP Raw Socket in IPv4 in both cases: End-host and router (in contrast to IPv6). By telling the kernel we want a UDP raw socket we require the kernel to send us all UDP packets terminating at the local node (where we are end-host). By telling the kernel we want to intercept Router Alter Option packets (we do so by calling setsockopt() on the raw socket) we require the kernel to send us all UDP packets with Router Alert Option even if we are not end hosts.
IIRC in the former case (we are end-host) the ICMP error is sent. We use the raw socket here because we want to see the IP header of the packet to inspect Q-Mode vs. D-Mode encapsulation (i.e. to test if the RAO was present).
- Configuration via setsockopt?
Yes. We would need a way to tell the kernel that this raw sockets takes care of UDP packets coming in on port X and that there is no need to generate a ICMP error.
Christian
nsis_imp@informatik.uni-goettingen.de