Static NAT can currently be done on VyOS, but they're a pain if you have a lot of them.
For example -
Headquarters Local Vyos Remote Office Vyos Remote Offices
>--- tun0 169.254.254.1/30 <--> tun0 169.254.254.2/30 --- 192.168.1.0/24
Corp 172.16.0.0/12 >--- tun1 169.254.254.5/30 <--> tun0 169.254.254.6/30 --- 192.168.1.0/24
>--- tun2 169.254.254.9/30 <--> tun0 169.254.254.10/30 --- 192.168.1.0/24In this particular situation the remote offices always have to have the same ip scheme.
To make each office reachable by headquarters, we need a static nat in place.
Traffic is received for the nat address at the remote office tun and translated to the internal address.
Traffic from the internal address destined to the corp network is translated to the nat address.
Remote Office 1 10.0.1.0/24 Corp >> 10.0.1.10 <--> tunnel0 <--> 192.168.1.10 192.168.1.10 <--> tunnel0 <--> 10.0.1.10 >> Corp Remote Office 2 10.0.2.0/24 Corp >> 10.0.2.10 <--> tunnel1 <--> 192.168.1.10 192.168.1.10 <--> tunnel0 <--> 10.0.2.10 >> Corp Remote Office 3 10.0.3.0/24 Corp >> 10.0.3.10 <--> tunnel2 <--> 192.168.1.10 192.168.1.10 <--> tunnel0 <--> 10.0.3.10 >> Corp
Now you can easily connect to all your offices, even though they have the same IP scheme at each location.
Currently you can do this with a combination of both a source nat and destination nat, as such -
vyos@vyos# show nat
destination {
rule 10 {
destination {
address 10.0.1.10
}
inbound-interface tun0
translation {
address 192.168.1.10
}
}
}
source {
rule 10 {
outbound-interface tun0
source {
address 192.168.1.10
}
translation {
address 10.0.1.10
}
}
}This gets to be pretty intense after 100 static nats, or 200 nat rules overall.
It be nice if we could take a more Juniper approach and do something like this -
static {
rule 10 {
destination {
address 10.0.1.10
}
inbound-interface tun0
translation {
address 192.168.1.10
}
}
}At which point it would create both the source and destination nat.
And of course, i can't bring this up without also saying we should incorporate zone based nats.
static {
rule 10 {
destination {
address 10.0.1.10
}
inbound-zone VPN
translation {
address 192.168.1.10
}
}
}That way if you had redundant tunnels (e.g. vtun0 <-> Corp Vyos 1 & vtun1 <-> Corp Vyos 2) you wouldn't have to double up on the number of nat rules.
Of course, that would only apply if the firewall config was zone based traffic.