Jool Stateful is not respoding with ICMP Port Unreachable errors for a certain scenario. #173

Closed
crisdeleon opened this Issue Sep 25, 2015 · 1 comment

Comments

Projects
None yet
2 participants
@crisdeleon
Contributor

crisdeleon commented Sep 25, 2015

Jool Stateful is not respoding with an ICMP Port Unreachable error to an external pier that is trying to open a connection with a TCP SYN when it (Jool) receives a UDP package with same src and dst IPv4#port combination as the TCP SYN that openned a connection.

What I did:
n4 sends a nc -p 4141 -n 192.0.2.2 64134
Then
n6 sends a nc -u -n 64::192.0.2.11 4141

=================================================
Catching IPv4 packet: 192.0.2.11->192.0.2.2
Step 1: Determining the Incoming Tuple
Tuple: 192.0.2.11#4141 -> 192.0.2.2#64134 (TCP)
Done step 1.
Step 2: Filtering and Updating
BIB entry: None
Session entry: ::#0 - 64::c000:20b#4141 | 192.0.2.2#64134 - 192.0.2.11#4141 (TCP)
Pkt queue - I just stored a packet
Done: Step 2.
=================================================
Catching IPv6 packet: 2001:db8:2::11->64::c000:20b
Step1: Determining the Incoming Tuple
Tuple: 2001:db8:2::11#51987 -> 64::c000:20b#4141 (UDP)
Done step 1.
Step 2: Filtering and Updating
BIB entry: 2001:db8:2::11#51987 -> 192.0.2.2#64134 (UDP)
Pkt queue - I just cancelled an ICMP error
Session entry: 2001:db8:2::11#51987 - 64::c000:20b#4141 | 192.0.2.2#64134 - 192.0.2.11#4141 (UDP)
Done: Step 2.
Step 3: Computing the Outgoing Tuple
[...]
=================================================

To achieve this scenario, you need to predict the port that the NAT64 will use to mask the outgoing packet. To make this particular scenario easier to preproduce, you can reduce the UDP pool to only 1 port and force jool to always mask the packet with the same port. In the scenario before, my pool4 is UDP 192.0.2.2 64134-64134. It can be any port.

This way the outside pier doesn't need to guess the port NAT64 will use, and always send the packet to the port 64134.

@ydahhrk ydahhrk added this to the 3.4.0 milestone Sep 25, 2015

@ydahhrk

This comment has been minimized.

Show comment
Hide comment
@ydahhrk

ydahhrk Sep 25, 2015

Member

Ok, so what's happening here is

If an UDP packet (or its translated counterpart) happens to have the same IP transport addresses as a TCP Simultaneous Open (SO) currently taking place, it messes up the SO.

Only TCP packets should alter the SO state.

Thankfully, it's easy to fix.

Member

ydahhrk commented Sep 25, 2015

Ok, so what's happening here is

If an UDP packet (or its translated counterpart) happens to have the same IP transport addresses as a TCP Simultaneous Open (SO) currently taking place, it messes up the SO.

Only TCP packets should alter the SO state.

Thankfully, it's easy to fix.

ydahhrk added a commit that referenced this issue Sep 30, 2015

Issues #173 and #174.
Regarding #174:
Er... In the end, I decided to accept nonzero u-bits only if --force is present.
This looks more intuitive IMO, as opposed to printing a message in stderr but succeeding anyway.

@ydahhrk ydahhrk closed this Nov 10, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment