Jool_siit not translating a destination in particular

[elysch]

Hello.

Can't find out why my working jool_siit, isn't doing it's work for a specific address.

The entry in the eamt has a /128 prefix for the IPv6 address and a /32 CIDR for the IPv4 one. (as you can see in the 3rd section of the image).

When I manually query the jool_siit it answers with the right values, as you can see in the 1st section of the image. But it's not translating the traffic.

The logging-debug shows the specific entry in the eamt is not being recognized, as you can see in the 2nd section of the image.

¿What can I do to fix this or further analyze it?

Environment information (sensitive information replaced by "X" or "x"):

[root@XXXXXX ~]# cat /etc/system-release
Oracle Linux Server release 8.8
[root@XXXXXX ~]# uname -a
Linux XXXXXX 5.15.0-104.119.4.2.el8uek.x86_64 #2 SMP Fri Aug 18 20:16:10 PDT 2023 x86_64 x86_64 x86_64 GNU/Li
nux
[root@XXXXXX ~]# jool_siit --version
4.1.10.0
[root@XXXXXX ~]# jool_siit -i default global display
  manually-enabled: true
  pool6: xxxxxxxxxxxxxxxxxx:a3::/96
  lowest-ipv6-mtu: 1280
  logging-debug: false
  zeroize-traffic-class: false
  override-tos: false
  tos: 0
  mtu-plateaus: 65535,32000,17914,8166,4352,2002,1492,1006,508,296,68
  amend-udp-checksum-zero: false
  eam-hairpin-mode: intrinsic
  randomize-rfc6791-addresses: true
  rfc6791v6-prefix: (unset)
  rfc6791v4-prefix: (unset)
[root@XXXXXX ~]#

Thanks

Ely

Note: To be sure there was no error in the IPv6 address, I copied from the first section to search into de logs... that's why it has white background the "40::80" in the 2nd section of the image

[ydahhrk]

What about the source address? Is that translatable?

[ydahhrk]

New commit on main. Jool now states the offending address:

Jool SIIT/8a815600/default: ===============================================
Jool SIIT/8a815600/default: Packet: 10.0.2.2->10.0.2.15
Jool SIIT/8a815600/default: TCP 53972->22
Jool SIIT/8a815600/default: Translating the Packet.
Jool SIIT/8a815600/default: Unable to translate 10.0.2.15: Address is subnet-scoped or belongs to a local interface.
Jool: Returning the packet to the kernel.

[elysch]

Hello again.

I changed my origin. The thing is nothing to/from the "...40::80" appears on the logs anymore. Wierd. I confirmed with tcpudmp the packets are comming in.

This image shows in yellow one tcpdump entry and the search of the "...40::80" string in the "journalctl -xe" not showing any results:

The entry is still there in the eamt:

(I downloaded the main branch from github, compiled and installed jool_siit)

Any ideas why it's not working the translation?

[elysch]

Hello again.

I changed my origin. Also downloaded the github main branch, compiled and installed it.

The thing is i'm getting exactly the same message

Confirmed the entry is still in the eamt and the other translations are still working.

Any ideas?

P.S 1: It's wierd the messages in the logs not always appear or at least not immediately. My previous message (that I hided) was about there were no appearance of the translation at all in the journalctl. After a while I found some. Maybe there are two problems?. Or just a buffer thing.

P.S 2: What IPv4 origin it would use after translation (ipv6 to ipv4)? The last 32 bits of the IPv6 origin address, right?

P.S. 3: The destination in the eamt is like XXXX:XXXX:XXXX:XXXX::80. Of course shouldn't matter, but I also tried with XXXX:XXXX:XXXX:XXXX:1:2:3333:3380 since 3333:3380 hex is 51.51.51.128 decimal. It also gives the same error.

[elysch]

Hello again.

Downloaded the github main branch, compiled, uninstalled the previous one and installed the new one.

The previous destination in the eamt was like XXXX:XXXX:XXXX:XXXX::80. Of course shouldn't matter, but I also tried with XXXX:XXXX:XXXX:XXXX:1:2:3333:3380 since 3333:3380 hex is 51.51.51.128 decimal (is translatable).

I changed my origin. It could be converted to ipv4 like: 152.219.108.69

The requests aren't being translated still:

Why is it complaining about the origin ip and not seing the destination ip do have a record in the eamt?

The eamt entry is:

The problem could be that jool is comparing first ipv6 addresses to the defined pool6, instead of first looking for an entry in the eamt?. That way you cannot translate an arbitrary ipv6 to ipv4 if there is a defined pool6 to translate from IPv4 to IPv6

Am I right? Is there a workaround?

I would like to avoid the need to use different namespaces, but I cannot think of a way to have an instance of jool_siit with a pool6 defined and another instance without it.

Maybe would be easier to use as destination one IP from the pool6. Right?

[elysch]

Hello again.

I changed the destination IPv6 address to use one of the pool6 ones with no success, But again... I changed the destination IP and jool doesn't permit the origin IP.

The received message is:

sep 04 11:21:02 TRSFDPT02 kernel: Jool SIIT/8f958000/default: ===============================================
sep 04 11:21:02 TRSFDPT02 kernel: Jool SIIT/8f958000/default: Packet: 2806:106e:13:**xxxx**:34ba->2001:**xxxx**:a350
sep 04 11:21:02 TRSFDPT02 kernel: Jool SIIT/8f958000/default: TCP 54060->443
sep 04 11:21:02 TRSFDPT02 kernel: Jool SIIT/8f958000/default: Translating the Packet.
sep 04 11:21:02 TRSFDPT02 kernel: Jool SIIT/8f958000/default: Unable to translate 2806:106e:13:**xxxx**:34ba: Address lacks both pool6 prefix and EAM.
sep 04 11:21:02 TRSFDPT02 kernel: Jool: Returning the packet to the kernel.

2001:xxxx:a350 now is included in the pool6 defined:

[root@**xxxx** ~]# jool_siit global display
  manually-enabled: true
  pool6: 2001:**xxxx**::/96
  lowest-ipv6-mtu: 1280
  logging-debug: false
  zeroize-traffic-class: false
  override-tos: false
  tos: 0
  mtu-plateaus: 65535,32000,17914,8166,4352,2002,1492,1006,508,296,68
  amend-udp-checksum-zero: false
  eam-hairpin-mode: intrinsic
  randomize-rfc6791-addresses: true
  rfc6791v6-prefix: (unset)
  rfc6791v4-prefix: (unset)
[root@**xxxx** ~]#

Thanks in advance.

[ydahhrk]

Why is it complaining about the origin ip and not seing the destination ip do have a record in the eamt?

Because the destination ip doesn't have anything to do with your problem. The source and destination addresses are completely independent from each other.

When Jool has to translate an IP header, it needs to turn this into this. If you look at those "Source [IP] address" fields, there's nothing optional about them.

The destination needs to be translatable. The source ALSO needs to be translatable. The translated source address is not inferred from the original destination address; it's inferred from the original source address.

If you look at all the tutorials in Jool's website, as well as our past troubleshooting, you should notice that I've designed all my sample networks in such a way that Jool has a means to translate both addresses, not just the destination.

The problem could be that jool is comparing first ipv6 addresses to the defined pool6, instead of first looking for an entry in the eamt?

Why do you think this? Nothing in your outputs suggest that you have an EAMT entry that matches 2806:106e:13::.

[elysch]

Ok, I see.

When I said the source is translatable, in fact I was thinking that it was possible to change last two hextets to an ipv4 address. Now I see jool doesn't do that.

Please refer me to the proper documentation, or:

Could you please explain how would be de communication between c6 and s4 in the SIIT-DC-2xlat Documentation please? (originating at c6). Please show before and after the ER source and destination IPs.

As far as I can tell, 2001:2b8::ab:cd is not defined on any one of the two EAMT shown. It's communication would have the same problem as I have?.

C6 searches 2001:12:34::4 and that appears in de ER's EAMT, but the 2001:2b8::ab:cd does not. And the 2001:2b8::ab:cd address could be any global address.

I'm sorry to bother you with such a basic question, but I don't get it.

Thanks in advance.

Ely

[ydahhrk]

As far as I can tell, 2001:2b8::ab:cd is not defined on any one of the two EAMT shown. It's communication would have the same problem as I have?.

Yes. And the reason for that is that it's completely out of scope of the problem SIIT-DC solves. SIIT-DC is meant for DCs (Data Centers), not ISP customer clusters like 464XLAT.

Normally, the IPv4 island where s4 is located wouldn't exist. In an ideal SIIT-DC scenario, every single node in your DC would be IPv6-only, and IPv4 can be simply seen as a "service" provided by the BR.

But sometimes, as a Data Center, you need to host legacy servers that do not support IPv6 at all. Emphasis on "do not support IPv6 at all." These services have IPv4 hardcoded up to the communication protocol, so even if you could translate c6's address, c6 and s4 still would probably not be able to understand each other. That's why you don't care about c6's translatability. c6 is only meant to talk to your IPv6 nodes; s6a and s6b.

And the 2001:2b8::ab:cd address could be any global address.

Yes, precisely. And because it's any global address, it's not translatable unless you use NAT64.

Unless you want to single out c6, in which case you can add it to the EAMT. But at that point it wouldn't be "any" global address.

[ydahhrk]

As the first letter of its name implies, s4 is a server. Which means it's under your control.

If the server supports IPv6, it's better if you just move it to the IPv6 side. (And purge the IPv4 island.)

[elysch]

well... yes... eventually there shouldn't be any IPv4 server...hahaha.

I configured NAT64 acording to the documentation, can see in the debug log successes on attending my requests (both 6->4 and 4->6), but the web page doesn't load (ERR_CONNECTION_TIMED_OUT).

I'll try to find out what is happening, and get back to you.

One question... is there any limitation on running jool and jool_siit in the same server (same namespace)?

Thank you so much.

Ely :)

[ydahhrk]

One question... is there any limitation on running jool and jool_siit in the same server (same namespace)?

Wouldn't recommend it. They will interfere with each other.

[ydahhrk]

I would like to close this issue as part of the 4.1.11 release.

If a problem persists, feel free to reopen.