I’m replacing a tunneled gateway using VyOS.
I got it online, the tunnel up, OSPF, all that’s left is to set up full cone, or static port NAT
I can’t find information about it in the documentation though. How can I do this? This is v1.4, BTW.
Thanks!
masqueraded works with source-nat :
https://docs.vyos.io/en/latest/configuration/nat/nat44.html#configuration-examples
I not sure what is the idea , is port mapping with source nat or destination . it could be changing the logic to apply . maybe we need a full example to give a recommendation.
‘Port NAT’ Means Destination NAT ?
Like this?
set nat destination rule 100 destination port '1688'
set nat destination rule 100 inbound-interface 'pppoe0'
set nat destination rule 100 protocol 'tcp'
set nat destination rule 100 translation address '192.168.11.10'
Thanks for answering,
Since obviously I can’t explain myself correctly — sorry about that — I doodlled over a screenshot:
I was referring about source NAT, thought it’s more like a 1:1 NAT since the addresses that would be used for the translation are static and forwarded to a single address, but given I’m both trying to solve a problem, and at the same time educate myself on how to deal with this with more common dynamic addresses, PPPoE as you guys mention — like the example above: it’s dynamically addressed interface used for masquerading anything outgoing through it keeping the ports straight. It’s not used for 1:1, incoming [new] traffic is processed if there are DNAT/PAT rules for it.
In the case of the VyOS instance, it’s very close to 1:1 NAT, the public static addresses of the VyOS router are mostly 1:1ed to a single point down a tunnel, with some exceptions, or at least that’s what I’m trying to replace. But like I said, for 1:1 the address needs to be known which is not commonplace on most small networks.
Thanks again!
it’s more clear , where it seems to use a source-nat with masquerade , although the option static-port doesn’t make any reference , however, when we performing a source- nat mesquerade keep source-port when using outgoing interface :
basic eg.:
set nat source rule 100 outbound-interface 'eth0'
set nat source rule 100 source address '0.0.0.0/0'
set nat source rule 100 translation address 'masquerade
therefore , it’s possible to assign a static range port to the source when defining this nat source .
So, let me see if I got this,
And thanks for answering BTW. Those three lines are actually the same amount of information required in the setup above (pfSense):
masquerade” or another placeholder/macro for a dynamic address
And I’m just reading in the screenshot that ports should not be specified with static port translation. That’s odd, since since the filed is cleared and grayed out by the marking the checkbox next. I digress, though not to much since it’s actually related to what follows.
“it’s possible to assign a static range port” — so many questions this raises, I’ve rewritten this four-five times already, I hope it’s clear enough;
When you throw in range (of) port(s), source, assign and define/ing, in that single sentence, does it mean as a filter/match to NAT the traffic or for the public impersonation, if you will, of the source once it’s natted? i.e+e.g;
1st case the former / as filter
Traffic would be natted only if it comes from high ports YX to YZ. This is also an option above, it’s blank though an asterisk is accepted as well meaning the rule will match if the traffic comes sourced from the specified ports in the box. Note that this rule above as it is NATs beyond just port-based protocols, GRE, ESP, ICMP, etc covered too, the more fields left blank the wider the scope of the rule to match traffic.
2nd case the latter / impersonation
Regardless of what’s the original port the client host used to connect, publicly, connections will always originate from ports 30002 to 30004.
Also, if the port range is omitted, does it mean it it won’t be randomized (i.e. stays static) or the opposite? And if I do set the port range and it’s used as in the 2nd case, wouldn’t that just be symmetric NAT but with extra steps?
If those three lines are all that’s needed though, you’re going to make my day week, Full-cone is the last thing I need to sort out to adopt VyOS. Yesterday, I think, I found out that VyOS can reverse-proxy as well and I’m more determined that ever. Thanks again!
I think I found it !
Is it something like:
set nat source rule 100 translation options port-mapping none? 
I went on command line safari, and found once again I think similar ambiguous port-related option or the one you mentioned:
vyos@vyos# set nat source rule 100 translation port
Possible completions:
<1-65535> Numeric IP port
<start>-<end> Numbered port range (e.g., 1001-1005)
“to translate”, “translated into”, I don’t know, anything is better than “translation” alone which can mean any of the three significant port places for NAT: original source port, translated/after translation source port and destination port. Make that four with translated destination port. I sort of forgot the most common one.
vyos@vyos# set nat source rule 100 translation options port-mapping
Possible completions:
random Randomize source port mapping
fully-random Full port randomization
none Do not apply port randomization (default)
Finally! I’ve yet to pass traffic over the week old tunnel but I’m feeling super confident never mind the fact that I’m a total noob.
According to the CLI, it would seem like static ports are the default, but on the documentation this note it’s what fueled my tailspin:
When using NAT for a large number of host systems it recommended that a minimum of 1 IP address is used to NAT every 256 private host systems. This is due to the limit of 65,000 port numbers available for unique translations and a reserving an average of 200-300 sessions per host system.
It makes it seem like (1) all ports are used are exploited so there’s little or no reuse and/because (2) VyOS considers NAT a security feature. It’s not.
Anyway, thanks again nevertheless!
Well NAT is a security feature when it comes to its fairly tricky for an outside host to establish a connection to a inside host without a portforwarding in between (or be dependent that the inside host does something like establishing a connection to the outside host or talking to a STUN server or similar).
That is in the case where inside is SNAT to outside (aka masquerade).
“Normally” one want the srcport to be randomized when doing SNAT simply because you “normally” have more than 1 host behind that SNAT. But its good to have a 1:1 option available mainly for cases where there are a single host thats being SNATed for whatever reason.
Makes life so much easier on receiving end.
Not uncommon example is when using NAT-traversal (UDP encapsulation) when doing IPsec.
By the default the key exchange will use the same srcport and dstport aka IKEv2 (UDP500 if I recall it correctly) where the encrypted tunnel itself will use UDP4500 as both srcport and dstport.
When the above gets SNATed it will arrive at destination with a srcport different than UDP500 and UDP4500 and that might cause issues depending on how the destination firewall is setup (that is if it accepts srcport>1023 for both dstport UDP500 and UDP4500 or if it only accepts srcport=500 for dst UDP500 and srcport=4500 for dst UDP4500).
I 'm wondering is that possible to set reverse proxy with haproxy on vyos to fit for your need? currently vyos 1.4 support haproxy reverse proxy function.
Haproxy can proxy only TCP/HTTP/HTTPS traffic
Yes, Sure. If the connection is not auth with active directory. As far as I know, maybe nginx is a good choice. Sine Nginx supports upd proxy and tcp/http/https proxy.
Without any port setting, masquerade will try to keep the source port identical . So source port selected on LAN-client will not be altered on source NAT. (which resembles full cone)
There is a limit of 64k ports. But theoretically ports can be used more than once: Each entry in NAT translation table holds remote address/remote-port local-WAN-Address/local-ports, so if you contact different remote servers, you could use same source port. Not sure if VyOS can handle that though