Lan to Lan NAT
-
Hello,
I am new to PF sense and need to perform a LAN to LAN NAT.
I have two subnets, opt1 - 192.168.110.0 and opt2 - 172.19.25.0.
Only opt1 has a dhcp server, Opt2 has been assigned 172.19.25.41 as it will reside on a customer network.
I need to be able to hit 172.19.25.41 and be redirected to 192.168.110.120.
So far I have tried a inbound NAT and had some success, I can see the state being created but am not receiving a reply from 192.168.110.120. A 1:1 NAT with no success and a outbound NAT without success.
Is there anything I am missing or is there a better way to go about this with PF sense ?
Any help would be appreciated.
-
@david01 Why do you want/need to do this. If 2 networks are directly connected to pfsense why could you not just go to the 192 address.. Do these devices not have a gateway set?
-
I need to keep the networks isolated and only give access to 192.168.110.120 through 172.19.25.41.
Only op1 has a gateway.
-
@david01 so opt1 your 192 network has gateway that points to pfsense IP on opt1? So this 172.19.25.41 would have to be IP on the opt2 interface of pfsense, this is pfsense IP on this network?
If so all that is needed is typical port forward on the opt2 interface.
Unless you have firewall run on your hosts on 192.168 network there is no problem with simple port forward.
You didn't happen to select block rfc or bogon on your opt2 interface?
-
Yes, opt1 ( Lan ) is using the default gw and seems to be working as it should.
Yes that's correct, 172.19.25.41 is the IP of the opt2 interface which does not have a gateway associated.
I have run through and ensured the block rfc / bogon option is not ticked on both opt1 and opt2.
When using a port forward I can see the state being created and it seems to be correct however I am not receiving a response from 192.168.120.110:502
I have also made sure I have a "Allow any" rule on both interfaces.
-
@david01 well if you see the state created, but no answer.. You sure you don't have a firewall on the 192.168 device.. This is common problem..
You can sniff on the opt1 interface, then try and make a connection from device on your opt2 network.. If you see the packet go out, and get no response - then the problem is not with pfsense.
you can do sniff in pfsense via packet capture under diagnostic menu
-
Thanks, I will give that a go, Their shouldn't be as its a PLC but it is Siemens so who knows their might be some funky subnet stuff going on with it.
I can definitely hit it on opt1 without issue, Is there a way I can create a virtual IP on opt1 and route 172.19.25.41 ---- > 192.168.120.150 ( Virtual IP ) -----> 192.168.120.110 ( PLC ) so it appears that it is being queried from the same subnet ?
Please keep in mind I am pretty new to PFsense, I've mainly used WatchGuard products in the past.
-
@david01 sure if for some reason the device on opt1 network will only allow access from the local opt1 network you could also do a source nat (outbound nat) so you get this
192.168.110.x -- 192.168.110.y (pfsense) 172.19.25.41 -- 172.19.25.x
So your 25.x guy hits 25.41, it gets forwarded to 192.168.110.x, outbound out of pfsense it changes it to look like its coming from 192.168.110.y
-
Thanks, That might be the winner, I couldn't spot any responses coming from 110.120 on opt 1 when jumping through 25.41 on opt2 using a port forward ( Inbound NAT ? ).
I did try a outbound NAT earlier without any luck, I may have missed something in the config , Do you have any good examples you can point me towards please ?
-
@david01 sure I could show you an example.. But its really late here, I will show a good example of this in the morning.. Pretty easy to setup.
-
Thanks, I will check back tomorrow.
-
@david01 ok here go..
So I have 2 interfaces, my lan 192.168.9/24 and wlan 192.168.2/24
Pfsense IP
lan = 192.168.9.253
wlan = 192.168.2.253Now I have a pc on lan 192.168.9.100, and AP on wlan with IP 192.168.2.2
Now pfsense listens on 22, so couldn't use that port. So I setup a port forward on lan to port forward any traffic hitting 2222 on lan interface to 192.168.2.2 on 22
Then I created outbound nat on wlan interface says translate any traffic from 192.168.9/24 to 192.168.2.2 to the IP of pfsense on wlan
So when I send ssh traffic to 192.168.9.253 on port 2222, it gets sent to 192.168.2.2 22 and outbound changed to my pfsense IP 192.168.2.253
You can see via the sniff on the wlan interface that traffic is sent to 192.168.2.2 from 192.168.2.253 vs my 192.168.9.100
If I sniff on the lan side I see 9.100 sending to 9.253, and answer
-
@johnpoz Thanks for the reply !
Did you set up the inbound and outbound to get bi-directional NAT ?
I was thinking that was half of my issue so I tried a 1:1 NAT before I left the office again and failed,
From what I've read at home I needed to select proxy ARP instead of IP Alias when setting up the virtual IP and add a firewall rule that allowed any to the virtual IP on Opt2, I would of thought the allow any to any rule would cover it.
I wont be able to get back into the office until Sunday, I should be able to set it up remotely if the PC I left plugged in hasn't crashed but I need to physically be on the network to test,
Im a little confused as to why you've set the Dest, Address on the port forward to LAN Address and the NAT IP to 2.2 and left the source as any, But that might just be the late hour here.
-
@david01 no it is not directional, you would have to set that up if you wanted opt2 to create traffic to opt1..
-
@johnpoz Ahh OK, 172.19.25.41 ---> 192.168.120.110 will be polled on port 502 and need to reply back on port 502 ( modbus )
-
@david01 said in Lan to Lan NAT:
192.168.120.110 will be polled on port 502 and need to reply back on port 502 ( modbus )
That would just be allowed by the state that is created. You do not need to create rules for return traffic. You only need to create rules for unsolicited traffic.
Sorry for the late response - long weekend just got back..
-
@johnpoz Sorry I didn't get back to you sooner,
I ran out of time to trouble shoot and ended up spinning up a quick ubuntu instance and doing a DNAT using IP tables.
I did run through your example without success, I could see the messages hitting the destination on the correct port but it wasn't replying for whatever reason.
Seems to work fine using a IP table, I guess the DNAT is successfully making it appear as the messages are originating from the 110.0 subnet and satisfying whatever siemens have going on.
