Does anyone have experience in combining these two?

I run a he.net tunnel that arrives in my LAN on a dedicated Raspberry Pi that acts as the end point of the tunnel. On the Pi I then run radvd across my LAN to assign other devices an IPv6 address.

I have a Debian buster box that I have assigned a static IPv6 address in the GUI config and from a terminal can ping -6 google.co.nz from the box just fine.

I can also run BinkD and poll out to an IPv6 address fine also.

The problem is getting incoming IPv6 connections to BinkD etc. to work.

I have UFW as the firewall, I have enabled IPv6 in the UFW config settings and added ports like 24554 which when I check the status I can see the port is enabled for both IPv4 and IPv6

To Action From
-- ------ ----
24554/tcp ALLOW Anywhere
24555/tcp ALLOW Anywhere
24554/tcp (v6) ALLOW Anywhere (v6)
24555/tcp (v6) ALLOW Anywhere (v6)

My router has port forwarding enabled from the WAN to the static IPv4 on the Debian box and certainly for IPv4 traffic all is good.

I'm stuck as to know why I can't seem to get ports open for my IPv6 address when I have UFW seemingly enabled.

Now the Pi that acts as the end point of the tunnel has a static IPv4 and IPv6 address perhaps I need to enable something in UFW for that address(ess)?

I'm also wondering if it's something to do with the tunnel stuff.

But it feels like I'm 90%+ sorted as I know the Debian box can happily poll outbound BinkD traffic without issue.

Any help appreciated.

Best, Paul

--- Mystic BBS v1.12 A47 2021/09/29 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 11 Oct 2021, Paul Hayton said the following...

The problem is getting incoming IPv6 connections to BinkD etc. to work.

I have UFW as the firewall, I have enabled IPv6 in the UFW config
settings and added ports like 24554 which when I check the status I can see the port is enabled for both IPv4 and IPv6

To Action From
-- ------ ----
24554/tcp ALLOW Anywhere 24555/tcp ALLOW Anywhere 24554/tcp (v6) ALLOW Anywhere (v6) 24555/tcp (v6) ALLOW Anywhere (v6)

My router has port forwarding enabled from the WAN to the static IPv4 on the Debian box and certainly for IPv4 traffic all is good.

I'm stuck as to know why I can't seem to get ports open for my IPv6 address when I have UFW seemingly enabled.

Now the Pi that acts as the end point of the tunnel has a static IPv4
and IPv6 address perhaps I need to enable something in UFW for that address(ess)?

I'm also wondering if it's something to do with the tunnel stuff.

But it feels like I'm 90%+ sorted as I know the Debian box can happily poll outbound BinkD traffic without issue.

Any help appreciated.

Hi Paul,

Have you verified that traffic isn't already getting to the system it needs to, just there's another firewall on that system? with IPv6 if I'm not mistaken it has a more direct path to the system rather than a standard kind of NAT through the router/firewall?

Maybe run tcpdump on the target system to see if any packets of data hit it, and then you could know 100% whether they're making it there, and getting filtered on the target system, or if not, you could trace it back to the firewall or the router.

Also check the IPv6 endpoint system has forwarding enabled, i.e. your IPv6 debian host;

$ sysctl net.ipv6.conf.all.forwarding
net.ipv6.conf.all.forwarding = 0

If you get a 0 it's not enabled, so enable it with;

$ sudo sysctl -w net.ipv6.conf.all.forwarding=1

Then run that previous command again to check that it's enabled, then "hopefully" you should be good, of course it may already be enabled and this is not a valid suggestion, but it's what's comming to my mind just now.

Hope it does help, and isn't wasting your time.

---
|14Best regards,
|11Ch|03rist|11ia|15n |11a|03ka |11Me|03aTLoT|11io|15N

|07ÄÄ |08[|10eml|08] |15ml@erb.pw |07ÄÄ |08[|10web|08] |15www.erb.pw |07ÄÄÄ¿ |07ÄÄ |08[|09fsx|08] |1521:1/158 |07ÄÄ |08[|11tqw|08] |151337:1/101 |07ÂÄÄÙ |07ÄÄ |08[|12rtn|08] |1580:774/81 |07ÄÂ |08[|14fdn|08] |152:250/5 |07ÄÄÄÙ
|07ÄÄ |08[|10ark|08] |1510:104/2 |07ÄÙ

... Everyone is entitled to my opinion!

--- Mystic BBS v1.12 A47 2021/08/10 (Linux/64)
* Origin: thE qUAntUm wOrmhOlE, rAmsgAtE, uK. bbs.erb.pw (21:1/158)

$ sysctl net.ipv6.conf.all.forwarding
net.ipv6.conf.all.forwarding = 0

If you get a 0 it's not enabled, so enable it with;

$ sudo sysctl -w net.ipv6.conf.all.forwarding=1

Then run that previous command again to check that it's enabled, then "hopefully" you should be good, of course it may already be enabled and this is not a valid suggestion, but it's what's comming to my mind just now.

EDIT: To make the change active, run this;

$ sudo sysctl -p

(I forgot to add this to the last message)

---
|14Best regards,
|11Ch|03rist|11ia|15n |11a|03ka |11Me|03aTLoT|11io|15N

|07ÄÄ |08[|10eml|08] |15ml@erb.pw |07ÄÄ |08[|10web|08] |15www.erb.pw |07ÄÄÄ¿ |07ÄÄ |08[|09fsx|08] |1521:1/158 |07ÄÄ |08[|11tqw|08] |151337:1/101 |07ÂÄÄÙ |07ÄÄ |08[|12rtn|08] |1580:774/81 |07ÄÂ |08[|14fdn|08] |152:250/5 |07ÄÄÄÙ
|07ÄÄ |08[|10ark|08] |1510:104/2 |07ÄÙ

... Press any key to continue or any other key to quit...

--- Mystic BBS v1.12 A47 2021/08/10 (Linux/64)
* Origin: thE qUAntUm wOrmhOlE, rAmsgAtE, uK. bbs.erb.pw (21:1/158)

On 11 Oct 2021 at 08:37a, MeaTLoTioN pondered and said...

Have you verified that traffic isn't already getting to the system it needs to, just there's another firewall on that system? with IPv6 if I'm not mistaken it has a more direct path to the system rather than a standard kind of NAT through the router/firewall?

I'll disable UFW and do another IPv6 port test using a web based port checker tool but I think it will fail. In which case I guess, yes it could be another firewall or some IPtables stuff that ships with Debian out of the box perhaps?

What I can seem to do is using another PC on my LAN, poll the BinkD server using IPv6 that can't currently be reached externally.

Here's the log at 1/100 as my 1/10 system polls it from within the LAN

- 12 Oct 14:17:53 [1311] incoming from 2001:470:d:123:918b:abed:6187:cc92 (62365)
+ 12 Oct 14:17:54 [25343] incoming session with 2001:470:d:123:918b:abed:6187:cc92
- 12 Oct 14:17:54 [25343] SYS fsxNet Games + Usenet Gateway
- 12 Oct 14:17:54 [25343] ZYZ Avon
- 12 Oct 14:17:54 [25343] LOC Dunedin, New Zealand
- 12 Oct 14:17:54 [25343] NDL 115200,TCP,CM,MO,BINKP
- 12 Oct 14:17:54 [25343] TIME Tue, 12 Oct 2021 14:17:50 +1300
- 12 Oct 14:17:54 [25343] VER binkd/1.1a-99/Win32 binkp/1.1
+ 12 Oct 14:17:54 [25343] addr: 21:1/10@fsxnet
- 12 Oct 14:17:54 [25343] OPT NDA EXTCMD CRYPT GZ BZ2
+ 12 Oct 14:17:54 [25343] Remote supports asymmetric ND mode
+ 12 Oct 14:17:54 [25343] Remote supports EXTCMD mode
+ 12 Oct 14:17:54 [25343] Remote requests CRYPT mode
+ 12 Oct 14:17:54 [25343] Remote supports GZ mode
+ 12 Oct 14:17:54 [25343] Remote supports BZ2 mode
- 12 Oct 14:17:55 [25343] TRF 0 0
+ 12 Oct 14:17:55 [25343] Remote has 0b of mail and 0b of files for us
+ 12 Oct 14:17:55 [25343] pwd protected session (MD5)
- 12 Oct 14:17:55 [25343] session in CRYPT mode
+ 12 Oct 14:17:55 [25343] done (from 21:1/10@fsxnet, OK, S/R: 0/0 (0/0 bytes))

Maybe run tcpdump on the target system to see if any packets of data hit it, and then you could know 100% whether they're making it there, and getting filtered on the target system, or if not, you could trace it
back to the firewall or the router.

Sad to say I'm a n00b at this tool but up for anything to try and suss where the pipes are blocked :)

--- Mystic BBS v1.12 A47 2021/09/29 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 11 Oct 2021 at 08:37a, MeaTLoTioN pondered and said...

Have you verified that traffic isn't already getting to the system it needs to, just there's another firewall on that system? with IPv6 if I'm not mistaken it has a more direct path to the system rather than a standard kind of NAT through the router/firewall?

OK with UFW disabled the website checker port test shows still shows closed for IPv6 on 24554

I can however ping (as I could before I disabled UFW) the Debian box from the outside world.

I ran tcpdump ip6 on my Debian box and could see that traffic coming into the box and the box replying. Other than that there's little traffic lots of UDP stuff...

[snip]

14:48:46.915613 IP6 fe80::a450:12f1:b06d:393c.61701 > ff02::c.1900: UDP, length 146
14:48:49.916885 IP6 fe80::a450:12f1:b06d:393c.61701 > ff02::c.1900: UDP, length 146
14:48:53.915547 IP6 fe80::a450:12f1:b06d:393c.61701 > ff02::c.1900: UDP, length 146
14:48:56.913660 IP6 fe80::a450:12f1:b06d:393c.61701 > ff02::c.1900: UDP, length 146
14:48:59.913333 IP6 fe80::a450:12f1:b06d:393c.61701 > ff02::c.1900: UDP, length 146
14:49:02.447762 IP6 fe80::ba27:ebff:fe60:17b > ip6-allnodes: ICMP6, router advertisement, length 56
14:49:03.915586 IP6 fe80::a450:12f1:b06d:393c.61701 > ff02::c.1900: UDP, length 146
14:49:06.931934 IP6 fe80::a450:12f1:b06d:393c.61701 > ff02::c.1900: UDP, length 146
14:49:09.913305 IP6 fe80::a450:12f1:b06d:393c.61701 > ff02::c.1900: UDP, length 146
14:49:11.943849 IP6 hexillion.com > orac: ICMP6, echo request, seq 44746, length 40
14:49:11.943885 IP6 orac > hexillion.com: ICMP6, echo reply, seq 44746, length 40
14:49:12.158220 IP6 hexillion.com > orac: ICMP6, echo request, seq 44747, length 40
14:49:12.158244 IP6 orac > hexillion.com: ICMP6, echo reply, seq 44747, length 40
14:49:12.372275 IP6 hexillion.com > orac: ICMP6, echo request, seq 44748, length 40
14:49:12.372304 IP6 orac > hexillion.com: ICMP6, echo reply, seq 44748, length 40
14:49:12.586854 IP6 hexillion.com > orac: ICMP6, echo request, seq 44749, length 40
14:49:12.586883 IP6 orac > hexillion.com: ICMP6, echo reply, seq 44749, length 40
14:49:12.802225 IP6 hexillion.com > orac: ICMP6, echo request, seq 44750, length 40
14:49:12.802250 IP6 orac > hexillion.com: ICMP6, echo reply, seq 44750, length 40
14:49:13.913335 IP6 fe80::a450:12f1:b06d:393c.61701 > ff02::c.1900: UDP, length 146
14:49:16.650707 IP6 fe80::2c02:d338:8ebb:bc11.64485 > ff02::1:3.hostmon: UDP, length 22
14:49:16.749773 IP6 fe80::2c02:d338:8ebb:bc11.64485 > ff02::1:3.hostmon: UDP, length 22


and later when I did a test IPv6 BinkD poll from 1/10 (in my LAN) to
the 1/100 Debian box I could see that traffic to.

[snip]

14:49:59.909080 IP6 fe80::a450:12f1:b06d:393c.61701 > ff02::c.1900: UDP, length 146
14:50:03.908188 IP6 fe80::a450:12f1:b06d:393c.61701 > ff02::c.1900: UDP, length 146
14:50:04.447784 IP6 2001:470:d:123:918b:abed:6187:cc92 > ff02::1:ff00:200: ICMP6, neighbor solicitation, who has orac, length 32
14:50:04.447815 IP6 orac > 2001:470:d:123:918b:abed:6187:cc92: ICMP6, neighbor advertisement, tgt is orac, length 32
14:50:04.448153 IP6 2001:470:d:123:918b:abed:6187:cc92.62435 > orac.binkp: Flags [S], seq 1514083003, win 8192, options [mss 1440,nop,wscale 2,nop,nop,sackOK], length 0
14:50:04.448183 IP6 orac.binkp > 2001:470:d:123:918b:abed:6187:cc92.62435: Flags [S.], seq 3182582046, ack 1514083004, win 64800, options [mss 1440,nop,nop,sackOK,nop,wscale 7], length 0
14:50:04.448467 IP6 2001:470:d:123:918b:abed:6187:cc92.62435 > orac.binkp: Flags [.], ack 1, win 16560, length 0
14:50:04.451925 IP6 orac.binkp > 2001:470:d:123:918b:abed:6187:cc92.62435: Flags [P.], seq 1:422, ack 1, win 507, length 421
14:50:04.513969 IP6 2001:470:d:123:918b:abed:6187:cc92.62435 > orac.binkp: Flags [P.], seq 1:227, ack 422, win 16454, length 226
14:50:04.514002 IP6 orac.binkp > 2001:470:d:123:918b:abed:6187:cc92.62435: Flags [.], ack 227, win 506, length 0
14:50:04.657826 IP6 2001:470:d:123:918b:abed:6187:cc92.62435 > orac.binkp: Flags [P.], seq 227:281, ack 422, win 16454, length 54
14:50:04.657846 IP6 orac.binkp > 2001:470:d:123:918b:abed:6187:cc92.62435: Flags [.], ack 281, win 506, length 0
14:50:04.659142 IP6 orac.binkp > 2001:470:d:123:918b:abed:6187:cc92.62435: Flags [P.], seq 422:470, ack 281, win 506, length 48
14:50:04.717952 IP6 2001:470:d:123:918b:abed:6187:cc92.62435 > orac.binkp: Flags [P.], seq 281:284, ack 470, win 16442, length 3
14:50:04.718264 IP6 orac.binkp > 2001:470:d:123:918b:abed:6187:cc92.62435: Flags [F.], seq 470, ack 284, win 506, length 0
14:50:04.718672 IP6 2001:470:d:123:918b:abed:6187:cc92.62435 > orac.binkp: Flags [.], ack 471, win 16442, length 0
14:50:04.769365 IP6 2001:470:d:123:918b:abed:6187:cc92.62435 > orac.binkp: Flags [F.], seq 284, ack 471, win 16442, length 0
14:50:04.769390 IP6 orac.binkp > 2001:470:d:123:918b:abed:6187:cc92.62435: Flags [.], ack 285, win 506, length 0
14:50:06.930026 IP6 fe80::a450:12f1:b06d:393c.61701 > ff02::c.1900: UDP, length 146

[snip]

So I'm left wondering is there something else on the debian box blocking IPv6 stuff if UFW is not running but it seems the tunnel is working to the box given it replies to IPv6 pings?

Where to look and adjust?

--- Mystic BBS v1.12 A47 2021/09/29 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 11 Oct 2021 at 08:37a, MeaTLoTioN pondered and said...

Also check the IPv6 endpoint system has forwarding enabled, i.e. your
IPv6 debian host;

$ sysctl net.ipv6.conf.all.forwarding

are you talking about the HUB that I am trying to allow systems to reach via IPv6 or the Raspberry Pi tunnel He.Net endpoint that is on the same LAN?

--- Mystic BBS v1.12 A47 2021/09/29 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 12 Oct 2021 at 03:52p, Avon pondered and said...

are you talking about the HUB that I am trying to allow systems to reach via IPv6 or the Raspberry Pi tunnel He.Net endpoint that is on the same LAN?

Just confirming the Raspberry Pi tunnel has the =1 setting for this command already

--- Mystic BBS v1.12 A47 2021/09/29 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 12 Oct 2021, Avon said the following...

On 12 Oct 2021 at 03:52p, Avon pondered and said...

are you talking about the HUB that I am trying to allow systems to re via IPv6 or the Raspberry Pi tunnel He.Net endpoint that is on the sa LAN?

Just confirming the Raspberry Pi tunnel has the =1 setting for this command already

Yes I was meaning the Raspberry Pi. So from your tests, you can see traffic getting to the box with the firewall off and on, but only a limited set of UDP packets, and the routing is correctly set for IPv6 on the Raspberry Pi.

You can poll internally with UFW enabled or disabled, so that rules out anything locally to do with the binkp server, leaving really only the router and it's forwarding options.

On your router do you have any options to see any logs and preferably packet logs from the firewall showing anything getting blocked which you can filter by host ip or mac etc?

---
|14Best regards,
|11Ch|03rist|11ia|15n |11a|03ka |11Me|03aTLoT|11io|15N

|07ÄÄ |08[|10eml|08] |15ml@erb.pw |07ÄÄ |08[|10web|08] |15www.erb.pw |07ÄÄÄ¿ |07ÄÄ |08[|09fsx|08] |1521:1/158 |07ÄÄ |08[|11tqw|08] |151337:1/101 |07ÂÄÄÙ |07ÄÄ |08[|12rtn|08] |1580:774/81 |07ÄÂ |08[|14fdn|08] |152:250/5 |07ÄÄÄÙ
|07ÄÄ |08[|10ark|08] |1510:104/2 |07ÄÙ

... If you choose not to decide, you still have made a choice

--- Mystic BBS v1.12 A47 2021/08/10 (Linux/64)
* Origin: thE qUAntUm wOrmhOlE, rAmsgAtE, uK. bbs.erb.pw (21:1/158)

On 12 Oct 2021 at 05:27a, MeaTLoTioN pondered and said...

Yes I was meaning the Raspberry Pi. So from your tests, you can see traffic getting to the box with the firewall off and on, but only a limited set of UDP packets, and the routing is correctly set for IPv6 on the Raspberry Pi.

I can see ping traffic coming into the Debian box (my NET 1 HUB etc.) which must be I am assuming coming in via the Pi tunnel using 6to4.

When UFW was on I checked the logs and found things like this

Oct 11 16:50:28 orac kernel: [431888.091741] [UFW BLOCK] IN=enp4s0 OUT= MAC=1c:6f:65:d7:70:04:f0:9f:c2:10:49:b8:08:00 SRC=159.69.42.106 DST=192.168.1.131 LEN=60 TOS=0x00 PREC=0x00 TTL=42 ID=60969 DF PROTO=TCP SPT=26156 DPT=24554 WINDOW=29200 RES=0x00 SYN URGP=0

So UFW has been doing some blocking when enabled for port 24554 but it does
not explain why when it's disabled I still can see an open port via IPv6.

Interestingly it looks like only my Edgerouter port forwarding is the cause
of the IPv4 port checker tests via web portal appearing to be open.

Another thing I found was there were entries when I looked at ip6tables and
the like... but it seems they may have been written by UFW?

I tired to figure out if iptables and ip6tables were active but came up short.

I wondered if something there was running as well on my Debian box.

Sadly I feel like I'm just thrashing around not really making any clear progress as I know not enough about linux nor all the tools but have been trying.

On the Edgerouter I just have a NAT rule to pass traffic destined for 24554
on to the local LAN IPv4 address of the Debian box and port 24554

There seemed to be options to allow protcol 41 to be specified (as some have suggested to me this may be an issue) but I can't state a port and such a protocol in the NAT rules, rather I must state tcp and/or udp when
specifying a port.

What's not clear is if it's some rule on the debian box or perhaps the
router. Yet when I had IPv6 and BinkD running on my windows box, it all ran fine and the settings that are currently in place in the router did the trick for incoming IPv6 traffic to work fine.

Perhaps I need to revisit the windows firewall settings for clues.

Sorry it's late and I'm waffling now.

I did just run the https://test-ipv6.com/ tests on the Debian box and got 10/10

Test with IPv4 DNS record
ok (0.171s) using ipv4
Test with IPv6 DNS record
ok (1.232s) using ipv6
Test with Dual Stack DNS record
ok (0.180s) using ipv4
Test for Dual Stack DNS and large packet
ok (0.066s) using ipv4
Test IPv6 large packet
ok (1.159s) using ipv6
Test if your ISP's DNS server uses IPv6
ok (0.178s) using ipv4
Find IPv4 Service Provider
ok (0.235s) using ipv4 ASN 4771
Find IPv6 Service Provider
ok (0.213s) using ipv6 ASN 6939

--- Mystic BBS v1.12 A47 2021/09/29 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

Avon wrote (2021-10-12):

Sadly I feel like I'm just thrashing around not really making any clear progress as I know not enough about linux nor all the tools but have been trying.

I know this feeling, especially with Linux where stuff is different between distributions. There is always some new component that is replacing an older component and distros and releases are at a different point in the transition from the old way to the new way. Good luck to find the answer to your problem that works out of the box on your current Linux setup and doesn't suggest doing everything completely differently.

On the Edgerouter I just have a NAT rule to pass traffic destined for
24554 on to the local LAN IPv4 address of the Debian box and port 24554

There seemed to be options to allow protcol 41 to be specified (as some have suggested to me this may be an issue) but I can't state a port and such a protocol in the NAT rules, rather I must state tcp and/or udp when specifying a port.

I have no experience with IPv6 tunneling, but I also would suspect that the router might do some filtering.

Why would you put a port in the NAT rules for IPv6 tunnel packets? As far as I understand an IP header does not have a port number. The port number is encoded in the TCP or UDP header.

Protocol 1: ICMP (for ping etc)
Protocol 6: TCP
Protocol 17: UDP
Protocol 41: IPv6 Encapsulation
(https://simple.wikipedia.org/wiki/Protocol_41
https://en.wikipedia.org/wiki/IP_protocol_number)

ICMP does not use a port number at all and Protocol 41 encapsulates a whole IPv6 packet. I imagine that there might be another place in your routers config where you can enable/forward Protocol 41.


Is it a Ubiquiti Edgerouter? https://community.ui.com/questions/Forward-protocol-41/ba78ff53-4557-4b92-b4d4-82828497167c
(no idea if there is anything useful in that thread)

---
* Origin: 1995| Invention of the Cookie. The End. (21:3/102)

Avon wrote to MeaTLoTioN <=-

If you're using UFW firewalling, insure on IPV4 you allow "protocol" (not port!) 41 Often people get these confused.

n1uro@n1uro:~$ cat /etc/protocols | grep 41
ipv6 41 IPv6 # Internet Protocol, version 6


... He does the work of 3 Men...Moe, Larry & Curly
--- MultiMail/Linux v0.52
* Origin: Carnage - risen from the dead now on SBBS (21:4/107)

On 12 Oct 2021 at 01:36p, N1uro pondered and said...

If you're using UFW firewalling, insure on IPV4 you allow "protocol"
(not port!) 41 Often people get these confused.

n1uro@n1uro:~$ cat /etc/protocols | grep 41
ipv6 41 IPv6 # Internet Protocol, version 6

Thanks I did look at this but it turned out that was not the issue, appreciate the nudge though :)

--- Mystic BBS v1.12 A47 2021/09/29 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 12 Oct 2021 at 11:23a, Oli pondered and said...

I know this feeling, especially with Linux where stuff is different between distributions. There is always some new component that is

:)

I have no experience with IPv6 tunneling, but I also would suspect that the router might do some filtering.

It was the end point of the tunnel. I'll post a follow-up in sec. Solved it now I think, can you check by polling ipv6.agency.bbs.nz and test 24554 and 24555 and 24556 please :)

--- Mystic BBS v1.12 A47 2021/09/29 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 12 Oct 2021 at 05:27a, MeaTLoTioN pondered and said...

Yes I was meaning the Raspberry Pi. So from your tests, you can see traffic getting to the box with the firewall off and on, but only a limited set of UDP packets, and the routing is correctly set for IPv6 on the Raspberry Pi.

Finally solved this (I hope) it was some missing forwarding rules in the ip6tables on the Pi. Talk about chasing my tail. When I finally ended up looking there I could quickly see a FORWARD rule to the new IPv6 static IP I have set on the Debian box was missing.

Lots of running around poking into all sorts of things but I think it's now sorted at 21:1/100, 3:770/1 and 21:1/101 are accepting IPv6 again. I hope! :)

Thanks for your thoughts and ideas (and everyone else too!) it's been appreciated.

Best, Paul

--- Mystic BBS v1.12 A47 2021/09/29 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

Finally solved this (I hope) it was some missing forwarding rules in
the ip6tables on the Pi. Talk about chasing my tail. When I finally
ended up looking there I could quickly see a FORWARD rule to the new
IPv6 static IP I have set on the Debian box was missing.

Congratulations!

I've been there, when your mind thinks the problem is somewhere but it
turns out to be somewhere else entirely.

Andrew

--
|03Andrew Pamment |08(|11apam|08)
|13Happy|10Land |14v2.0|08!|07


--- Talisman v0.25-dev (Linux/x86_64)
* Origin: HappyLand v2.0 - telnet://happylandbbs.com:11892/ (21:1/182)

On 13 Oct 2021 at 03:12p, apam pondered and said...

Congratulations!
I've been there, when your mind thinks the problem is somewhere but it turns out to be somewhere else entirely.

Yep and yep, I am greatly relieved to have sussed it out.

--- Mystic BBS v1.12 A47 2021/09/29 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

Finally solved this (I hope) it was some missing forwarding rules in the ip6tables on the Pi. Talk about chasing my tail. When I finally

I've been there, when your mind thinks the problem is somewhere but it turns out to be somewhere else entirely.

What I used to hate was banging my head against a problem for hours refusing
to stop until I fuigure it out, end up having to take a break. Re-cover all the previous ground, and with no apparent changes it decides to work.

Spec


*** THE READER V4.50 [freeware]
--- SuperBBS v1.17-3 (Eval)
* Origin: The future's uncertain, the end is always near. (21:3/101)

What I used to hate was banging my head against a problem for hours

Ahhh so you're one of those! A head banger...

--- Mystic BBS v1.12 A46 2020/08/26 (Linux/64)
* Origin: Storm BBS (21:2/108)

Spectre wrote to apam <=-

Finally solved this (I hope) it was some missing forwarding rules in the ip6tables on the Pi. Talk about chasing my tail. When I finally

I've been there, when your mind thinks the problem is somewhere but it turns out to be somewhere else entirely.

What I used to hate was banging my head against a problem for hours refusing to stop until I fuigure it out, end up having to take a break.
Re-cover all the previous ground, and with no apparent changes it
decides to work.

Overthinking a situation often leads to making the issue worse. Rather than bang my head I simply walk away for a few minutes or so... 5-10 typically
for me is good enough... and then I usually (not always) can see what I've
been blinded to.

When running any sort of a tunnel, forwarding is required for it to fully
work on a full lan especially. The frames come in via sit# and tend to go
out via eth# which to the kernel would be packet forwarding. :)

--- MultiMail/Linux v0.52
* Origin: Carnage - risen from the dead now on SBBS (21:4/107)