[solved] NAT with unassigned destination IP
-
Hi! This could be a X/Y problem so I'll start with some (long-ish) background info:
We have two pfsense appliances with hardware redundancy.
Let's say I have a WAN, a LAN and another exotic external private subnet linked to an interface, let's call it SEN (Something Else Network)
Our problem: a subnet coming from WAN must reach a specific server in SEN subnet, but WAN has its own routing (I have no power over it) that doesn't include SEN addressing, the only way WAN traffic can reach my gateway is if it's pointing to a LAN address.
Our solution was a port forwarding NAT rule: if that particular subnet coming from WAN interface is pointing to a particular (free and unassigned) LAN ip, every port is forwarded to the SEN server.
Issue #1: are there more correct/elegant/appropriate approach to this kind of problem?
Issue #2: the solution doesn't really work at the moment and we don't see anything blocked in firewall rules. Maybe the NAT port forwarking works only if the destination address is somehow directly managed? (i.e.: we have to create another CARP ip in LAN interface only for NAT purposes?)
thanks in advance for any help
-
Please draw a network diagram of what is located where in the scenario. I understood zero of your description.
-
@kpa:
Please draw a network diagram of what is located where in the scenario. I understood zero of your description.
I'll do what I can… meanwhile, In the hope to clarify my main question, the iptables rule I'm trying to migrate in pfsense is:
$IPTABLES -t nat -A PREROUTING -s $source_ip -d $lan_ip -j DNAT --to-destination $another_ip -
"but WAN has its own routing"
You mean the devices in your wan network do not use pfsense wan IP as their default gateway, and you want stuff in this wan network to be able to get to some network behind pfsense. And you can not touch the routing table of the device in wan network?
So in a nutshell you have this - with example networks.. So your wan 192.168.0 uses a different gateway than pfsense wan IP lets call it 192.168.0.254.. And you want these devices in wan to be able to get to something in say 192.168.2/24?
-
Thank you very much for the drawing!
You mean the devices in your wan network do not use pfsense wan IP as their default gateway, and you want stuff in this wan network to be able to get to some network behind pfsense. And you can not touch the routing table of the device in wan network?
So in a nutshell you have this - with example networks.. So your wan 192.168.0 uses a different gateway than pfsense wan IP lets call it 192.168.0.254.. And you want these devices in wan to be able to get to something in say 192.168.2/24?
It's a little bit different (I'll use names and subnets of your drawing), the 192.168.0/24 has another gw/router before arriving to PfS Wan inteface and the only traffic allowed to get there is for the subnet 192.168.1/24.
So what I did with the previous gw was to NAT all traffic to a specific 192.168.1/24 address to the server on 192.168.2/24
-
So you have something like this?
And this other router is also natting between what I show as 192.168.0 and 192.168.3?
Please draw your network so we can all be on the same page of what your trying to do and where you have nats and what routes and default gateways you have on what devices, etc.
-
Please draw your network so we can all be on the same page of what your trying to do and where you have nats and what routes and default gateways you have on what devices, etc.
I've attached a drawing.
Quick recap using network subnets of my drawing:
-
the issue: 192.168.70.0/24 should reach a server in 10.1.100.0/24
-
the gateway of 192.168.70.0/24 (not managed by me) doesn't know about 10.1.100.0/24, to him my pfsense manages only 172.20.1.0/24
-
in the previous appliance (using iptables) we were doing it with a rule like: $IPTABLES -t nat -A PREROUTING -s 192.168.70.0/24 -d 172.20.1.214 -j DNAT –to-destination 10.1.100.214
-
-
- in the previous appliance (using iptables) we were doing it with a rule like: $IPTABLES -t nat -A PREROUTING -s 192.168.70.0/24 -d 172.20.1.214 -j DNAT –to-destination 10.1.100.214
So you had 172.20.1.214 assigned as a virtual IP on the previous routers interface connected to 192.168.20.1/24 and simple forwarded it to 10.1.100.214.
To do that on pfSense, go to Firewall > Virtual IPs and assign 172.20.1.214 as "IP Alias" to the proper interface.
Then add a port forwarding rule in "Firewall > NAT". Again select the proper interface, the protocol you need, at source hit "display advanced", select Network and enter 192.168.70.0/24, at destination select the virtual IP you've added before and at "redirect target" enter 10.1.100.214, below you may set a description, save the rule.
Now it should behave the same way as with the previous router.
-
Yup viragomann hit it right on the head and beat me to the punch ;)
Nice drawing btw - see how easy and clear now everyone understands how you had it setup and makes more sense.
But to be honest why could you not just use the IP that pfsense has on its wan as the dest, or create a vip in that transit network between the router and pfsense.
-
Yeah, a simple drawing says more then 1000 words. ;)
-
Thank you viragomann and johnpoz!
To do that on pfSense, go to Firewall > Virtual IPs and assign 172.20.1.214 as "IP Alias" to the proper interface.
This is the information I was missing: the rule was correct but I didn't know I had to configure a IP alias for that.
The complete resolution (should anyone be in this situation) included also creating a outbound nat rule I forgot about (to manage the return path from 10.1.100.214 back to 192.168.70.0/24)
Nice drawing btw - see how easy and clear now everyone understands how you had it setup and makes more sense.
But to be honest why could you not just use the IP that pfsense has on its wan as the dest, or create a vip in that transit network between the router and pfsense.
I couldn't use the wan interface or the transit network for multiple reasons:
first: I simplified my network topology, I actually have three situation like this to manage (think other two PfS optX interfaces with other subnets) and some of the servers are ftp servers so I'd rather have one virtual ip with all ports forwarded to a particular server (opposed to: single virtual ip with different NATs on different ports).
second: the transit network is really a transit network: it's a /29 subnet with almost no unassigned ip and that particular subnet it's managed by their router and my pfsense (its addressing it's opaque to my lan and the wan)Sorry about the delay with the drawing and the issues with the descriptions (english is not my first language), in the future I'll start threads only if I have a drawing ready :)
Thanks again
-
"the transit network is really a transit network: it's a /29 subnet with almost no unassigned ip"
Then why would you show it as a /24?
Going forward be as accurate as possible - there have been so many times that thread drags on because info given by the user is just not correct. Or they forget to say they are using proxy or captive portal, etc. etc… Correct info is a requirement to finding the problem..
This is why screenshot of rules and configs are best vs some one saying yeah I have port forward xyz or yup the rule is any any.. When you come to find out they had put in some source port on their port forward or the any any rule was tcp only, etc.
Or sure they do the port forward but they have block rule ahead of it on the wan, etc.
-
"the transit network is really a transit network: it's a /29 subnet with almost no unassigned ip"
Then why would you show it as a /24?
Going forward be as accurate as possible - there have been so many times that thread drags on because info given by the user is just not correct. Or they forget to say they are using proxy or captive portal, etc. etc… Correct info is a requirement to finding the problem..
The transit network was not actually showed in my drawing: as I said, I simplified some things, but I get your point. I only thought that reporting our whole network topology seemed a little overkill since the main question was on how to migrate a (pre exisiting and functioning) nat rule.
Anyway: ok, message received, won't happen again.
-
Per your drawing that 172.20.1/24 is clearly a TRANSIT network…
