Ah, I had not considered this, one wonders whether this is not a misdesign, the relevant IP addresses should all be in the IP header... and the SIP registrar should always pass out "external" addresses. But my what do I know, all I wanted to stress is that port-remapping truly is nasty 
The person you're talking SIP to is not necessarily the person you're going to talk voice RTP to. For example my ATA says "Hi I want to make a call to phone number xxxxxx@mysipservice and I want audio to come to me at MYIP" and then the sipservice says "ok, let me set up a call with a carrier..." and it tells the carrier "set up a call to phone number xxxx and send the audio to MYIP and tell me where we should send our audio? and then the carrier says "Fine, here's the call I'm sending my audio to MYIP and you should send your audio to CARRIERIP"
all those quoted messages are essentially SIP messages, but they travel from my ATA to my service provider, not to the carrier's Audio path. so it's not a misdesign but it is a complex set of connections that makes any kind of NAT truly nasty.
EDIT: of course, in the presence of NAT there are tons of work-around, but they're all unreliable hacks that truly suck and reduce reliability... and yes port-remapping is the worst. IPv6 is truly the future of VOIP telephony specifically due to it returning to the end-to-end nature of the internet, with public IP addresses at each endpoint.
Thanks for spelling it out, I think I now see the issue I would have guessed the SIP server would know the external addresses of both endpoints and send them a packet saying please contact the following externally visible IP address, that way address re-mapping should not be an issue...
1 Like
Many of the workarounds do work like that, but the sip packets do not need to go to the same place as the rtp packets, and so even if the sip server knows the external addresses that sip messages are coming from, it doesn't mean it knows anything about where the audio necessarily needs to go. Furthermore SIP messages can be proxied multiple times, sometimes it's normal for them to be forwarded 3 to 5 times before they reach their destination.
For example you could have several hundred servers at a carrier each processing audio, while a separate load-balancing SIP proxy handles the call set up and tear down via SIP messages, your provider's sip server knows about this load balancer, but doesn't necessarily know about which of the many audio servers deep inside the carrier infrastructure is handling the audio... unless that information is in the message from the carrier's SIP load balancer... which of course it is. Similar thing occurs inside a large business with hundreds of telephones, all sitting behind NAT... which IP address to hand to might be deducible (since everything inside the NAT actually just looks like 1 IP externally) but which port to hand off to... is completely impossible to determine. The workaround for that is often that the phone does some kind of STUN and figures out if there's a consistent port mapping, and if so, which port it should ask audio to be sent to.
The final workaround is often to have an external server that isn't natted relaying the audio for you. It's pretty inefficient but it does let you make connections.
Generally the world will be a better place for VOIP after ipv6 without NAT.
It seems this conversation has went into VoIP and IPv6, but the OP was talking about VPN...
To the OP, @yaa110, please let us know if this works, as I now need to do an IPv6 NAT only on a VPN tunnel. I have IPv6, but need to NAT when using the VPN because I'm only issued a single /128 IP.
Well, he was talking about NAT and we were discussing the evils of NAT and how in IPv6 it should be avoided.
While technically this means you have ipv6... the truth is you don't have IPv6 
guidelines for ipv6 are that the minimum is to issue /64 and most providers should be issuing a /60 or /56
are you sure that your provider won't issue at least a /64 if you adjust some settings so that your DHCP-PD requests are in line with what they expect? What provider do you have? If it's possible to fix your assignment this is by far the better way to go than to set up NAT. Yes I understand you don't have control over your ISP's stuff, but an ISP that rolls out only /128 is... wonky
I know, I noted this above, I was shocked my VPN provider only issued a /128.
I'm sure, I just setup an Azire VPN (see https://www.azirevpn.com/wireguard), I'm certain they're only issuing a /128. I also have Hurricane Electric, they issue /48 and /64's, no problem at all.
I installed kmod-ipt-nat6 and IPv4 worked already, I'm just trying to add the correct IPv6 routes as well, because my public IPv6 address still shows as Hurricane Electric on my test machine.
interesting, on their website https://www.azirevpn.com/wireguard at the bottom, they show how to get a bunch of stats in the form of a JSON response using curl... the JSON example strongly suggests an ipv6 prefix discovery handing out a /56 network prefix... perhaps you should look into configuration issues, as this seems promising.
EDIT: also they show things like:
/etc/wireguard/azirevpn-se1.conf example file
[Interface]
PrivateKey = 65G7oyb9jGxFXSCceTuFPHjjbPF2WVOCeNJ1SgPzzWk=
DNS = 193.180.164.2, 2a03:8600:1001::2
Address = 10.18.1.182/24, 2a03:8600:1001:1080::10b4/64
[Peer]
PublicKey = bdR5gm5vcrm9N9I7BeQqHOgrmQApSGIe9qc1homBjk8=
Endpoint = 193.180.164.60:51820
AllowedIPs = 0.0.0.0/0, ::/0
which strongly suggests that they're handing out a DHCP address that's part of a /64 but doesn't mean you couldn't use additional addresses in that /64 range. Hard to say exactly without looking into it more. I suspect there is a Prefix Delegation method, but perhaps your router isn't set up to request that delegation over the vpn link?
Yes, they do hand out an IP with /56 notation...but IP x:x:1 in that network is the gateway, therefore, I'm not the only host in the network, and hence, it's not a routed (issued) /56, it's really a routed /128 from a /56 network.
I've checked already...I've also attempted to assign myself another IP in that subnet, that didn't work either, only the /128 returned in the API works.
When you run the equivalent of their last command, what output do you get?
curl -d list=1 -d username=REPLACE --data-urlencode password=REPLACE --data-urlencode pubkey=REPLACE https://api.azirevpn.com/v1/wireguard/connect/se1
with appropriate modifications for your situation.
Do you get something that includes lines like:
"ipv6_pd": "2a03:8600:100c::",
"ipv6_pd_netmask": 56
as in their example? If so, can you use that _pd response to put a prefix on your LAN and route that _pd prefix over the tunnel?
EDIT: note that in their example they have:
"endpoint_ipv6_addr": "2a03:8600:1001:1337::1081",
which is not in the _pd network, so that's what I expect you to have on your VPN virtual interface, but the prefix delegation should allow you to delegate a separate prefix onto the LAN.
No, I did not. I received:
{
"status": "success",
"data": {
"DNS": "xxx.xxx.xxx.xxx, xxxx:xxxx:xxxx:xxxx::2",
"Address": "<IPv4_HERE>, <IPv6_HERE/64>",
"PublicKey": "<PUB_KEY_HERE>",
"Endpoint": "<SERVER_IP_HERE>"
}
As I noted, the only IP in the /64 that works was the /128 IP listed in the reply.
you included the "list=1" that they mention to get the more detailed results?
Please, just tell me how I do it over, instead of NAT6, then...
(I thought this thread was regarding NAT6...)
There is both NAT66 and NPTv6 in the Linux kernel and both work flawlessly on OpenWrt since 15.05. However they are not supported natively by LUCI aka OpenWrt's own "IPv6 stack".
For NAT66 you need to enforce IPv6 connection tracking in the firewall configuration for the respective interfaces/zones. By default OpenWrt doesn't track IPv6 packets. Then manually add the standard MASQUERADE rule to nat ip6table on the POSTROUTING chain.
Result: The kernel replaces all outgoing source IPv6 addresses with the WAN interface address. It works exactly like NAT44.
@jtsn, we covered this already, please read whole thread.
I'm now trying to set up NAT66 myself.
I noted that's my problem currently:
What further needs to be done???
I already have "masquerade" checked on the VPN Firewall Zone, but it still receive my other IPv6 addresses (meaning it's still using Hurricane for IPv6).
I'd prefer NAT66, after all, this is a VPN.
Right, you want to do NAT66 because you believe that your VPN provider doesn't give you anything but a single /128 address. But the provider's website suggests that this seems to be an erroneous belief, and that they actually do prefix delegation. However, you say that even with the "list=1" command in their example, you don't get what your provider says you should get... so I'm thinking maybe there's something wrong with the service, and that fixing that might be a better way to go compared to NAT66. But if you want to do NAT66 then... yes it can be done in theory, but I'm not sure how in LEDE. @jtsn has given you some suggestions perhaps that will work for you.
It's perfectly possible to have multiple prefixes on your LAN. Since you're not using any prefix delegation results from your VPN provider, you don't have any IPv6 addresses within the VPN provider's network to assign to your LAN devices... When your LAN devices try to make ipv6 connections, your router routes them down the HE tunnel because that's the only ipv6 route you have. You'll need to set up some kind of static route if you want it to go down the VPN tunnel instead. This is the main issue in my opinion.
No I didn't, I said:
I know this, and for a VPN, I'll have to disable forwarding via the other IPs...but you still didn't answer me, though.
How do I do it over?
I ran curl on Azaire again, I'll attempt to use the resulting data. I'll update you soon.
The last command on their page shows an output that is very different from the output that you posted, it includes 17 lines of data in the response. Yet you say that when you issue that command, you get only the 4 lines you mention. I then ask if you did in fact add the additional "-d list=1" portion of the command that their website requests you to add in order to get the more comprehensive 17 line response. I'm still not clear if you did that and still got only the 4 line response.
If in fact you got only the 4 lines even with the "-d list=1" portion of the command then it seems that the provider's website is misleading.
You seem to be convinced there is no choice but to set up NAT66, I'm less convinced of that.
If you want to setup NAT66 even though in fact you may be able to use prefix delegation etc. then I'm afraid you'll need help from someone more intimately familiar with the LEDE firewall than I am. Perhaps @jtsn understands how to set it up for LEDE.
I know this, I asked you how to do it again, since you keep mentioning it. I found out how to resubmit using this "list=1" argument already.
AGAIN, I DID NOT SAY THAT (hence me asking you twice HOW TO); but we covered that 2 times already.
AGAIN, I DID NOT SAY THAT.
Since you wouldn't tell me how, I did it myself. I now have a PD length...NOW WHERE DO I PLACE IT???
The Wireguard Interface entry does not have a place.