Hi!
They have asked me for a NAT something curious since I had never encountered this
I have 10 VPNs in routing to the local network, this is perfect, the VPN range 192.168.90.xxx and the local network 192.168.60.xxx, for various reasons they have asked me a few VPNs to access another network (192.168.61.0 / 24) must go as if they were a specific IP of the local network 192.168.60.111 via NAT
my problem is how to implement this NAT rule
I have thought of applying a src-adress in which if the IPs are from a list and have the 192.168.61.0/24 network as their destination, but I don’t know how to tell them to be the IP 192.168.60.111, that IP is only for this, The rest of the users should not be able to see it or access the MKT from this IP, is it possible?
I’ve been thinking about how to fix it for a long time and I have no idea how to do it
This NAT rule should be high on the NAT rule list, definitely above any other NAT rule which might trigger on same src/dst address pairs.
3. Optionally drop all other communication between VPN and the 192.168.61.0/24 network which is not src-nated:
Hi!
I thought that the to-address thing was to tell the NAT where to send all the traffic, but masking it as the IP that I have in ip-address declared in the bridge, at least that is how I have always used it to redirect internet ports to the local network , did not know this function
What you wrote looks like a description of a dst-nat operation to me.
The to-addresses is a parameter of an action, and its use depends on the particular action value:
for action=dst-nat, the to-addresses is a pool of new destination addresses - it can be specified as an individual address, a prefix (subnet) or a range
for action=src-nat, the to-addresses is a pool of new source addresses - it can be specified as an individual address, a prefix (subnet) or a range
for action=netmap, the to-addresses is a prefix to substitute the prefix of the destination or source address; which one is substituted depends on the chain where the action=netmap is used (srcnat or dstnat).
Chain dstnat processes the packets as they enter the router; chain srcnat processes them as they leave it.
@sindy already wrote about the meaning of to-address. In this particular case, router will rewrite source address of packet going from VPN towards its target to the set address.
Now, if the address belongs to router (somehow), then the return packet will land on router because of this fact. If address doesn’t belong to router, then arrival of return packet at router is not guaranteed. However, if path through which packet must travel to reach destination IP subnet (in this case from 192.168.61.x towards 192.168.60.111), is crossing your router, then it is fine to use such address any way, because router checks (inverse) SRC-NAT tables upon packet arrival regardless of destination address (either own address or anything else).
There would be a problem, if return packet would not pass router itself (e.g. because the next hop router would have IP address in destination subnet, e.g. 192.168.60.42, and would try to deliver return packet directly). It would probably fail (because probably there is no device using 192.168.60.111 in your LAN I suppose), thus connection would never establish (the same if there was a device using said address, but due to different reasons). If there isn’t a device using said address you can configure it on your router (either on interface where it’s current 192.168.60.x/24 resides or on a dummy bridge used in a loopback manner).
simple fact is that (firewall part of) router as part of connection tracking checks every incoming packet whether it’s part of NATed connection. An I mean every, regardless source and destination.
Let’s assume subnets 192.168.60.0/24, 192.168.61.0/24 and 192.168.90.0/24 can only talk with help of our router. Which means that VPN client can only talk to …61.x server via router. So router, due to SRC-NAT config, changes src-address of VPN’s packet to 192.168.60.111 (and possibly changes src-port if necessary). Server accepts connection and replies with dst-address set to the one from packet it received (which is 192.168.60.111). Return packet somehow arrives back at our router (either server knows to use our router for talking to 192.168.60.x/24 or another router - which happens to be server’s dedault gateway - knows that). Our router inspects packet and notices it belongs to a SRC-NATed connection, undoes the NATing (this time it replaces dst-address with address of VPN client which originally initiated the connection, possibly dst-port as well) and eventually forwards it to VPN host over VPN connection.
In short: take first right, third left and straight … there’s your Canadian rye destilate.
