Hello (IPv6) world! This is my sub-account for #IPv6 and related things. My main account is @litchralee
Public Key
npub1chvh052mdh8qe5qpt79hu5y4e6rgr0guc0thsxj9cmay9v973fvsygur8p
Profile Code
nprofile1qqsvtkth69dkmnsv6qq4lzm72z2uap5ph5wv84mcrfzud7jzkzlg5kgpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsany97v
Author Public Key
npub1chvh052mdh8qe5qpt79hu5y4e6rgr0guc0thsxj9cmay9v973fvsygur8p Show more details
Published at
2024-01-25T07:41:31+01:00 Event JSON
{
"id": "b1d3509df35673a0daffc4ec63207a9a352f0f4e7af6662c2dcc94e635136c28" ,
"pubkey": "c5d977d15b6dce0cd0015f8b7e5095ce8681bd1cc3d7781a45c6fa42b0be8a59" ,
"created_at": 1706164891 ,
"kind": 0 ,
"tags": [
[
"proxy",
"https://ipv6.social/users/litchralee_v6",
"activitypub"
]
],
"content": "{\"name\":\"Ti Nguyen\",\"about\":\"Hello (IPv6) world!\\n\\nThis is my sub-account for #IPv6 and related things. My main account is @litchralee\",\"picture\":\"https://ipv6.social/system/accounts/avatars/111/296/888/673/560/456/original/374470677fbb1c2c.png\",\"nip05\":\"[email protected] \"}" ,
"sig": "e812fa588951bbb4768e417a380f675ad9f3703b5e5925ea69b06169059cd9d391b7a315939507ed8ed7e82d309c0146e4d63efb01637ae89b7a3dd7f0bc8acb"
}
Last Notes npub1chvh052mdh8qe5qpt79hu5y4e6rgr0guc0thsxj9cmay9v973fvsygur8p Ti Nguyen @npub18nd…ax9z To be clear, does your internal network have working outbound connectivity to the IPv6 Internet? If not, I wonder if your firewall has a default rule to not forward. Also, I assume you have sysctl net.ipv6.conf.all.forwarding or equivalent enabled? npub1chvh052mdh8qe5qpt79hu5y4e6rgr0guc0thsxj9cmay9v973fvsygur8p Ti Nguyen @npub18nd…ax9z Might this be relevant? https://serverfault.com/questions/769374/firewalld-blocks-ipv6-ignores-config#comment1313551_775153 You might also want to see which firewalld rule is rejecting the connection, if you have that sort of logging available. npub1chvh052mdh8qe5qpt79hu5y4e6rgr0guc0thsxj9cmay9v973fvsygur8p Ti Nguyen @npub18nd…ax9z If I understand the question correctly, you're looking to expose a service on your internal network to be accessible from beyond your network, which is using firewalld as the firewall. Since there's no* NAT or masquerade to deal with in #IPv6, I think this should be as easy as adding a permit rule in firewalld, specifying the inbound protocol, the dst address, and dst port. This assumes you're using globally-addressed IPv6 addresses on your internal network. npub1chvh052mdh8qe5qpt79hu5y4e6rgr0guc0thsxj9cmay9v973fvsygur8p Ti Nguyen @npub1d8y…g8p7 In a domestic setting, I've yet to come across a need to enable MLD snooping, as there's more than sufficient L2 bandwidth to accommodate whatever multicast traffic I can reasonably imagine. For a #homelab or enterprise, it could make sense if you've got multi-tier switching -- to save inter-switch bandwidth -- but even then, that's often something to enable only after confirming a bandwidth shortage is caused precisely by multicast traffic. npub1chvh052mdh8qe5qpt79hu5y4e6rgr0guc0thsxj9cmay9v973fvsygur8p Ti Nguyen @npub1d8y…g8p7 My guess is that the tunnel endpoint (the Mikrotik) needs to specify a matching src/dst legacyIP pair that matches the dst/src pair on the other end of the tunnel. Otherwise, the far end could not identify this tunnel from others. Eg thousands of tunnels terminating at tunnelbroker.net Mikrotik may be smart enough to implicitly use the WAN IP when the local address isn't given. An explicit address might be necessary if behind certain NATs.