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 <[email protected]> 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 > [email protected] > https://mail-lists.nic.mx/listas/listinfo/jool-list > _______________________________________________ Jool-list mailing list [email protected] https://mail-lists.nic.mx/listas/listinfo/jool-list
