Hi Furry,
Not too much time to hang around on forums today, were you following some specific guide or tutorial on how to set things up?
For VLANs
here’s a brief primer:
It’s usually best to test the VLAN port by plugging in your laptop in that port and seeing what works what doesn’t.
Maybe routing / nat is fine in general and grandstream needs UPNP?
Check what works what doesn’t with your laptop.
Is sip/soft-phone an option you can test out?
For NAT:
… and SNAT/DNAT/hairpin/firewall stuff.
When you setup forwarding in a consumer router UI, behind the scenes you’re getting a DNAT rule in the firewall that rewrites the destination IP address within a packet coming from the internet, and you get a firewall hole that allows connections from any internet IP to your internal IP as long as the destination tcp or udp port is e.g. 1234.
UPNP allows software to do the same thing without having to bother a human to go into a webui and click on things.
DNAT == Destination NAT == NAT that overwrites the destination address of the original tcp/udp packet.
SNAT == Source NAT == NAT that overwrites the source address of the original tcp/udp packet.
This rewriting is done in the firewall in the “mangle” phase, which happens before the “filtering” phase. (phase of processing, people call it also “chain” or “table”).
For this rewriting to be practically useful, packets going in the other direction need to be re-written too and also whitelisted in the firewall symmetrically, otherwise you can’t really have connections. This other-direction-rewriting is not something that needs to be set-up manually - these SNAT and DNAT rules will automatically add connection tracking entries when they see the initial packet and will take care of mangling packets going in the other direction accordingly as well.
After the packets are mangled/rewritten, filtering comes along. If doing this manually, you’d need to ensure this original packet (when you want to allow a connection) makes a connection tracking entry, and then you’d need to ensure that future packets belonging to that connection going in either direction are allowed. This is not done automatically by any magical NAT rule. You’ll need at least 2 rules, one to allow any existing connection in a table (sometimes called related/established), and one to pick what to add into that table. e.g. anything originating on your LAN going to the internet, or anything coming from the internet to your LAN webserver onto port 8080. You’ll see this referred to as “statefull firewall” - since connection state is being tracked, or maybe referred to as “ctstate” in some places.
Hairpin Nat == not only redirect connections coming to the router from the internet, but also redirect connections from any other host on the same network. This is probably not useful to you for VoIP. It’s useful if you want to run a webserver at home and access it using the same public IP address and port as you would from the internet. (e.g. you’re using duckdns or similar). Reason this is a special case is because it requires using both DNAT and SNAT to pull off. If you were only using DNAT, browser host would send a packet to the router, router would rewrite dst ip, and send it to the webserver, webserver would look at where packet came from (your browser host) and would send a reply packet back to your browser host directly. Your browser host does not expect that packet since it thinks (or it only knows) that it’s talking to the router ip, so it discards this random looking packet and things don’t work. Additional SNAT fixes this by lying to the webserver - it overwrites the src ip of the packets as well, so that webserver replies to the router, which can then fix the src/dst IPs for your browser host, so that it too thinks it’s only talking to the router.
This NAT mess is why network people were enthusiastic about IPv6 originally. Turns out folks still want statefull firewalls even on IPv6 and having to know both IPv6 and IPv4 inside and out is strictly more complicated than knowing just one of the two.