Reply
Member
Posts: 128
Registered: ‎05-27-2015
Kudos: 12
Solutions: 6
Accepted Solution

Destination NAT with Masquerade

I have a scenario where an edgrouter is deployed to a remote location, receives a DHCP address from the LAN, builds a tunnel back to the datacenter, and needs to allow a print server to print to a printer on the LAN. The issue is the LAN uses the 192.168.1.0/24 subnet, which overlaps all over the place, and I can not change this. Nor can I create a route for this subnet on the print server.

 

What I want to do is

 

Print server -> VPN server - > vton0 on edgrouter -> masquerade to eth1 on edgrouter -> LAN

 

Destination NAT does not masquerade, and normally you don't want it to, so the printer responds by trying to route through the default gateway on the LAN subnet.

 

Is there a way to have destination NAT rules where they are masqueraded through the forwarded interface?


Accepted Solutions
New Member
Posts: 28
Registered: ‎12-14-2015
Kudos: 9
Solutions: 5

Re: Destination NAT with Masquerade

So you really need both DNAT and SNAT.  You need DNAT to hide the destination network (192.168.1.0/24) from the Print Server, and you need SNAT to hide the source network (192.168.10.0/24) from the MFP.

 

I think this can be done by using both types of NAT on different interfaces.

 

1. Add second IP address 192.168.11.3/24 to the vtun0 interface on the EdgeRouter.

2. Add DNAT to translate that destination address to the MFP, this translation operates on the vtun0 interface.

 

rule 10 {
description "DNAT to MFP"
destination {
address 192.168.11.3
}
inbound-interface vtun0
inside-address {
address 192.168.1.10
}
log disable
protocol tcp_udp
}
type destination

3. Add SNAT to translate the source address to the local EdgeRouter so that the MFP can talk back, this translation operates on the eth1 interface.

 

rule 20
description "SNAT to MFP"
log disable
outbound-interface eth1
outside-address {
address 192.168.1.5
}
protocol tcp_udp
source {
address 192.168.10.100
}
type source

Thus, the initial communication packet from the Print Server to the MFP operates as follows:

 

--> Source: 192.168.10.100, Destination: 192.168.11.3

--> Packet arrives at EdgeRouter vtun0 interface, DNAT operates:

--> Source: 192.168.10.100, Destination: 192.168.1.10

--> Packet gets routed through the EdgeRouter, gets sent to eth1 interface outbound based on the new destination address.

--> Packet arrives at eth1 interface queued for outbound, SNAT operates:

--> Source: 192.168.1.5, Destination: 192.168.1.10

 

--> MFP receives packet, thinks it's from the local network, so talks back to 192.168.1.5 without involving default gateway.

 

Now, dynamic translation table entries are in place for return traffic.

 

This only operates with TCP traffic initiated from the Print Server.  The MFP would not be able to initiate traffic to the print server with only these translation entries, e.g. MFP will not be able to ping the print server.  Print Server also will not be able to ping MFP because NAT entries are not set up to translate ICMP.

 

The Print Server must be told that the target printer is at 192.168.11.3, either by IP or DNS entry.  Print Server and print server's network do not need a route to 192.168.1.0/24.  PFSense box must have a route to 192.168.11.0/24 via tunnel, either statically assigned or via routing protocol, e.g. OSPF.  EdgeRouter must have a route to 192.168.10.0/24 via tunnel, either statically assigned or via routing protocol.

 

View solution in original post


All Replies
SuperUser
Posts: 5,837
Registered: ‎01-05-2012
Kudos: 1546
Solutions: 737

Re: Destination NAT with Masquerade

DNAT rules are usually on inbound interfaces, whereas SNAT rules on outbound interfaces, but, to be honest, I didn't fully understand the network topology and the needs ... Man Happy

Cheers,

jonatha

Member
Posts: 128
Registered: ‎05-27-2015
Kudos: 12
Solutions: 6

Re: Destination NAT with Masquerade

I will probably end up working with the remote site to rebuild their LAN to support our requirements anyway, was trying to get as much done remotely as possible.

Subnet A needs to reach IP on subnet C but only knows about tunnel IP B. Since the edgrouter is just another device on subnet C, and is not the default gateway, I want the devices on subnet C to think traffic from subnet A is coming from the subnet C IP the edgrouter is provided via DHCP.

I really wish we had IPv6....
Member
Posts: 128
Registered: ‎05-27-2015
Kudos: 12
Solutions: 6

Re: Destination NAT with Masquerade

192.168.10.100 uses default gateway 192.168.10.1 to reach 192.168.11.2
192.168.11.2, being the tunnel IP of the edgrouter, masquerades as 192.168.1.5 LAN address forwarding packets to 192.168.1.10.
192.168.1.10 uses default gateway of 192.168.1.1, which is not the edgrouter. Which is why I wanted to masquerade a DNAT.

VyOS does this by default. which has been frustrating. I have DNAT rules that get masqueraded as the firewall's LAN IP. So my internal servers do not know the true source IP. Was thinking Ubiquiti worked it out so that you could turn this on/off at will.
SuperUser
Posts: 5,837
Registered: ‎01-05-2012
Kudos: 1546
Solutions: 737

Re: Destination NAT with Masquerade

And a couple of masquearde rules ? The first, on the vtun0 (siteA), the second on the lan interface of the Edgerouter (siteC), if traffic is sourced from vtun0 ip address, masquerade with the LAN interface ip address ... Or you need L3 transparency ?

Member
Posts: 128
Registered: ‎05-27-2015
Kudos: 12
Solutions: 6

Re: Destination NAT with Masquerade

SiteA and SiteB can not have explicit routes for each other. The edgerouter is the only device that is aware of either subnet, and is the middle man.

SiteA does not have a route for SiteB, but does have a route for the tunnel subnet.
SiteB does not have a route for SiteA, but the edgrouter is on the same subnet as SiteB.

 

The situiation is more complicated than it needs to be. See attachment for diagram. Print server needs to communicate with MFP without explicitly knowing it's subnet.

 

 

example.jpg
SuperUser
Posts: 5,837
Registered: ‎01-05-2012
Kudos: 1546
Solutions: 737

Re: Destination NAT with Masquerade

On the VPN router (192.168.10.1) you can do PBR and forward traffic you want via the vtun0 ?

Member
Posts: 128
Registered: ‎05-27-2015
Kudos: 12
Solutions: 6

Re: Destination NAT with Masquerade

Yes (It's PFSense).
SuperUser
Posts: 5,837
Registered: ‎01-05-2012
Kudos: 1546
Solutions: 737

Re: Destination NAT with Masquerade

Not even the PFSense can have a static route for 192.168.1.0/24 network, via 192.168.11.2 , or vtun0 ? And if you send traffic from 192.168.1.100 to 192.168.11.2, then, a DNAT rule on the Edgerouter's vtun0, source 192.168.10.100, proto xx and dest.port yy, dest.addr 192.168.11.2, forward to 192.168.1.10, and a SNAT/masquerade rule on the eth1, condition source 192.168.10.100, proto xx and dest.port yy, dest.addr 192.168.1.10 ?

Member
Posts: 128
Registered: ‎05-27-2015
Kudos: 12
Solutions: 6

Re: Destination NAT with Masquerade

Even if PFSense had a route for 192.168.1.0/24, the MFP would not be able to reply. The issue with DNAT rules is the original source IP is passed along (which normally is ideal). In this case the MFP does not have a route back to 192.168.10.100, so it will try to use it's default which is the DSL modem.
SuperUser
Posts: 5,837
Registered: ‎01-05-2012
Kudos: 1546
Solutions: 737

Re: Destination NAT with Masquerade

The masquerade rule on eth1 should overcome this issue ...

Member
Posts: 128
Registered: ‎05-27-2015
Kudos: 12
Solutions: 6

Re: Destination NAT with Masquerade

I see what your saying, that should work as long as I don't have any other sites that use the 192.168.1.0/24 subnet. Which was something I wanted to avoid. If I can't avoid that then I will simply need to work with the remote site and have them use the edgrouter as their gateway.

I appreciate your time looking over this.
Highlighted
New Member
Posts: 28
Registered: ‎12-14-2015
Kudos: 9
Solutions: 5

Re: Destination NAT with Masquerade

Your main issue is that the MFP at 192.168.1.10 cannot reply to the print server's initial connection, because it has no route back to 192.168.10.100 other than the default route, which will go through the DSL modem.

 

You actually do not want DNAT here, what you need is SNAT.  Packets from 192.168.10.100 will get routed via the VPN router over the tunnel to the EdgeRouter, and the packet arrives at the EdgeRouter such:

 

Source: 192.168.10.100, destination 192.168.1.10

 

This packet needs to be translated such:

 

Source: 192.168.1.5, destination 192.168.1.10

 

This is source NAT (SNAT), with the operational interface as eth1.  The MFP now can respond to 192.168.1.5, which will reverse the NAT entry for return traffic.

 

You may want to add a "source group" element to the NAT rule entry to limit what source networks will get the translation applied on the way out eth1.

 

Member
Posts: 128
Registered: ‎05-27-2015
Kudos: 12
Solutions: 6

Re: Destination NAT with Masquerade

The problem with this solution is that the print server and/or PFsense must have a route for 192.168.1.0/24. Ideally I would want these devices to not be aware of the remote subnet since most homes/SMBs use 192.168.1.0/24 and I would be deploying more of these in the future. In the past I used Microtik routers to accomplish this.

Another recent example is an IoT device with a hardcoded subnet/address and no gateway (I was not part of the decision to buy this thing). I needed to access this device through the edgerouter pro in the office, but my workstation already used the same subnet for my VM lab. In this case I wanted to use masquerading on DNAT so I wouldn't have to change the VM lab subnet. In the end I renumbered the lab so I can access the poorly designed device.
New Member
Posts: 28
Registered: ‎12-14-2015
Kudos: 9
Solutions: 5

Re: Destination NAT with Masquerade

So you really need both DNAT and SNAT.  You need DNAT to hide the destination network (192.168.1.0/24) from the Print Server, and you need SNAT to hide the source network (192.168.10.0/24) from the MFP.

 

I think this can be done by using both types of NAT on different interfaces.

 

1. Add second IP address 192.168.11.3/24 to the vtun0 interface on the EdgeRouter.

2. Add DNAT to translate that destination address to the MFP, this translation operates on the vtun0 interface.

 

rule 10 {
description "DNAT to MFP"
destination {
address 192.168.11.3
}
inbound-interface vtun0
inside-address {
address 192.168.1.10
}
log disable
protocol tcp_udp
}
type destination

3. Add SNAT to translate the source address to the local EdgeRouter so that the MFP can talk back, this translation operates on the eth1 interface.

 

rule 20
description "SNAT to MFP"
log disable
outbound-interface eth1
outside-address {
address 192.168.1.5
}
protocol tcp_udp
source {
address 192.168.10.100
}
type source

Thus, the initial communication packet from the Print Server to the MFP operates as follows:

 

--> Source: 192.168.10.100, Destination: 192.168.11.3

--> Packet arrives at EdgeRouter vtun0 interface, DNAT operates:

--> Source: 192.168.10.100, Destination: 192.168.1.10

--> Packet gets routed through the EdgeRouter, gets sent to eth1 interface outbound based on the new destination address.

--> Packet arrives at eth1 interface queued for outbound, SNAT operates:

--> Source: 192.168.1.5, Destination: 192.168.1.10

 

--> MFP receives packet, thinks it's from the local network, so talks back to 192.168.1.5 without involving default gateway.

 

Now, dynamic translation table entries are in place for return traffic.

 

This only operates with TCP traffic initiated from the Print Server.  The MFP would not be able to initiate traffic to the print server with only these translation entries, e.g. MFP will not be able to ping the print server.  Print Server also will not be able to ping MFP because NAT entries are not set up to translate ICMP.

 

The Print Server must be told that the target printer is at 192.168.11.3, either by IP or DNS entry.  Print Server and print server's network do not need a route to 192.168.1.0/24.  PFSense box must have a route to 192.168.11.0/24 via tunnel, either statically assigned or via routing protocol, e.g. OSPF.  EdgeRouter must have a route to 192.168.10.0/24 via tunnel, either statically assigned or via routing protocol.

 

SuperUser
Posts: 5,837
Registered: ‎01-05-2012
Kudos: 1546
Solutions: 737

Re: Destination NAT with Masquerade

Did you read my previous post ??

Member
Posts: 128
Registered: ‎05-27-2015
Kudos: 12
Solutions: 6

Re: Destination NAT with Masquerade

I will have to play around with this. So far I have only used masquerade and DNAT, never used the SNAT type. In my lab, when I use a DNAT rule to a machine running tcpdump, I still see the original source address. Maybe the additional SNAT rule will take care of this.

Will get back with results.
Member
Posts: 128
Registered: ‎05-27-2015
Kudos: 12
Solutions: 6

Re: Destination NAT with Masquerade

@redfive
I might not have read it as you intended. My attention is split thirty different ways and this is relatively a low priority. If you were saying I can hide the source IPs without using an explicit route then my apologies.
Member
Posts: 128
Registered: ‎05-27-2015
Kudos: 12
Solutions: 6

Re: Destination NAT with Masquerade

@redfive
Yes indeed I did not read your solution correctly and you were correct.

@SomeJoe7777
Thank you for the organized code sample (aka pretty pictures for us simple people). It took me a second to figure out what was going on.

At one point I attempted to daisy chain the NAT rules, but I did not fully understand the order in which things were processed. Thanks for the help!
New Member
Posts: 28
Registered: ‎12-14-2015
Kudos: 9
Solutions: 5

Re: Destination NAT with Masquerade


@TurboAAAwrote:

So far I have only used masquerade and DNAT, never used the SNAT type.

 

SNAT and Masquerade operate nearly identically, the difference is that a Masquerade does not know the source IP address that it will be using in the translated packets in advance, because that IP address might be obtained via DHCP when a connection is finally made.  SNAT knows the translated IP address in advance, generally because the interface is statically assigned.

 

As an example, when a typical router is being configured, but before it has an Internet connection, the outbound interface has no IP address (yet).  However, you can still insert a masquerade rule into the router.  The masquerade rule will be set up to translate the source address of outbound packets to the primary IP address of the outbound interface, as soon as the interface obtains an IP address via DHCP.

 

In your case, the outbound interface is eth1, which is statically assigned to 192.168.1.5, and is known in advance.  Thus masquerade is not needed, just SNAT.

 

Reply