[Jool-list] returned IPv6 packets
Alberto Leiva
ydahhrk at gmail.com
Tue Aug 4 12:57:55 CDT 2015
Hello
> I have a scenario where I'm trying to use Jool along with an IP6-in-IPv4
> (ESP/IPsec) tunnel.
Ok; as long as the packet is decrypted before reaching Jool I don't
think there's anything strange about this.
> Packet #2 is odd, and something I'm investigating on the tcpdump side of
> things; it's the the IP6 packet coming out of the tunnel.
I'm not very familiarized with the IPSec protocol, but if you dump
this into a pcap file, maybe I can help with this.
> I can't see why it would be fragmented, given that it's 64-bytes.
> Bug?
Yes, sort of: It's an atomic fragment
(https://www.jool.mx/usr-flags-atomic.html). Jool felt the need to
include a redundant fragment header because of a combination of the DF
flag and the packet length. It's something RFC 6145 wants but it's
currently being deprecated.
Indeed, Jool 3.3 catched up with this fact and handles atomic
fragments better (by which I mean, it avoids them). It you upgrade,
the redundant fragment header should go away.
> Is there a way to dump "everything" in jool that relates to the state of it?
Yes; from less verbose to most:
- There's the Binding Information Base. This tells you the IPv4
transport address of each of your IPv6 transport addresses (not vice
versa, though). Here's more info: https://www.jool.mx/misc-bib.html
- There's the session table. This tells you everything Jool knows
about each connection alive being NAT64'd. See this:
https://www.jool.mx/usr-flags-session.html
- You can also enable debug. This logs each packet translation and any
reasons why it might have ended up in failure. For performance
reasons, this needs to be enabled while compiling. In Jool 3.3, simply
reinstall and activate the kernel module normally, except run `make
debug` instead of `make` while compiling. View the output running
`dmesg`. (the procedure is more annoying in Jool 3.2.)
Here's a sample output. Take heed of lines 2 (incoming packet
addresses), 4 (incoming packet addresses and ports), 12 (outgoing
packet addresses and ports), 16 ("translation was successful") and 17
("packet sent successfully"):
1 [ 1352.593185] ===============================================
2 [ 1352.593295] Catching IPv6 packet: 1::5->64:ff9b::c000:205
3 [ 1352.593342] Step 1: Determining the Incoming Tuple
4 [ 1352.593379] tuple IPv6-ICMP 1::5#3739 -> 64:ff9b::c000:205#3739
5 [ 1352.593405] Done step 1.
6 [ 1352.593411] Step 2: Filtering and Updating
7 [ 1352.595667] BIB entry: 1::5#3739 - 192.0.2.2#3356
8 [ 1352.595736] ICMP timer will awake in 60112 msecs.
9 [ 1352.595776] Session entry: 1::5#3739 -
64:ff9b::c000:205#3739 | 192.0.2.2#3356 - 192.0.2.5#3356
10 [ 1352.595808] Done: Step 2.
11 [1352.595815] Step 3: Computing the Outgoing Tuple
12 [1352.595842] tuple IPv4-ICMP 192.0.2.2#3356 -> 192.0.2.5#3356
13 [1352.595868] Done step 3.
14 [1352.595875] Step 4: Translating the Packet
15 [1352.595912] Done step 4.
16 [1352.595919] Sending skb via device 'eth1'...
17 [1352.595975] Success.
18 [1352.596213] ===============================================
19 [1352.596262] Catching IPv4 packet: 192.0.2.5->192.0.2.2
20 [1352.596294] Step 1: Determining the Incoming Tuple
21 [1352.596322] tuple IPv4-ICMP 192.0.2.5#3356 -> 192.0.2.2#3356
22 [1352.596349] Done step 1.
23 [1352.596355] Step 2: Filtering and Updating
24 [1352.596386] BIB entry: 1::5#3739 - 192.0.2.2#3356
25 [1352.596440] Session entry: 1::5#3739 - 64:ff9b::c000:205#3739
| 192.0.2.2#3356 - 192.0.2.5#3356
26 [1352.596472] Done: Step 2.
27 [1352.596478] Step 3: Computing the Outgoing Tuple
28 [1352.596505] tuple IPv6-ICMP 64:ff9b::c000:205#3739 -> 1::5#3739
29 [1352.596531] Done step 3.
30 [1352.596537] Step 4: Translating the Packet
31 [1352.596595] Done step 4.
32 [1352.596601] Sending skb via device 'eth0'...
33 [1352.596613] Success.
You want to turn this off when you're done because if the kernel is
storing logs it quickly eats up lots of disk space.
Hope this helps.
Good luck!
Alberto
On Mon, Aug 3, 2015 at 12:46 PM, Michael Richardson <mcr at sandelman.ca> wrote:
>
> I have a scenario where I'm trying to use Jool along with an IP6-in-IPv4
> (ESP/IPsec) tunnel.
>
> The setup looks like:
>
> +---------+ +-----------------------+
> | JJ (164)|===tunnel===|Parker(165) Jool(166) >---IPv4---
> +---------+ +-----------------------+
>
> My IP addresses are ULA: fd68:c9f9:4157::/48, with fd68:c9f9:4157:2:0:1::/96
> being the prefix given towards Jool. (I have an /etc/network/interfaces
> script that creates a macvlan interface, and runs dhcp on it to get another
> IPv4 address for Jool, since it can't share yet).
>
> The purpose of the setup is that the "parker" nodes are located in different
> parts of the Internet, and the JJ node can send packets to the IPv4 Internet
> From a central place, to get a view of the Internet from that location.
> (There are many other architectures that one could envision to do such
> proxying, but there are some legal advantages to this architecture which
> aren't relevant to the technology)
>
> Presently the two machines are VMs colocated on the same (NAT44, IPv6-native)
> LAN.
>
> Tcpdump on "parker":
>
> 1. 13:34:12.229238 IP 10.10.4.164 > 10.10.4.165: ESP(spi=0xb09a1f94,seq=0x6b), length 148
> 2. 13:34:12.229238 IP6 , wrong link-layer encapsulationbad-hlen 0
> 3. 13:34:12.229317 IP 10.10.4.166 > 8.8.8.8: ICMP echo request, id 59134, seq 107, length 64
> 4. 13:34:12.238962 IP 8.8.8.8 > 10.10.4.166: ICMP echo reply, id 59134, seq 107, length 64
> 5. 13:34:12.239000 IP6 fd68:c9f9:4157:2:0:1:808:808 > fd68:c9f9:4157::a0a:4a4: frag (0|64) ICMP6, echo reply, seq 107, length 64
>
> Packet #2 is odd, and something I'm investigating on the tcpdump side of
> things; it's the the IP6 packet coming out of the tunnel.
>
> I am running:
> JJ# ping6 -I fd68:c9f9:4157::a0a:4a4 fd68:c9f9:4157:2:0:1:8.8.8.8
>
> and as you can see, Jool is doing the right thing, sending out the v4 packet
> (step 3), receiving the replace (step 4), and forming an IPv6 packet... only,
> it's fragmented!
> I can't see why it would be fragmented, given that it's 64-bytes.
> Bug?
>
> This is jool 3.2.2, which I realize is a few months old, and I'll upgrade.
>
> Bug number two might well be that for some reason the xfrm IPsec stack is
> unable to match this fragment and put it in the tunnel.
> I will have to do some experiments to confirm/deny this part too.
>
> Is there a way to dump "everything" in jool that relates to the state of it?
> Maybe this is really everything?
>
> parker-[~] mcr 10238 %sudo jool -4
> 10.10.4.166
> (Fetched 1 addresses.)
> parker-[~] mcr 10239 %sudo jool -6
> 64:ff9b::/96
> fd68:c9f9:4157:2:0:1::/96
> (Fetched 2 prefixes.)
>
>
>
>
> _______________________________________________
> Jool-list mailing list
> Jool-list at nic.mx
> https://mail-lists.nic.mx/listas/listinfo/jool-list
>
More information about the Jool-list
mailing list