Lan to Lan NAT

David01

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.

johnpoz

@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

David01

@johnpoz

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 ?

johnpoz

@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.

David01

@johnpoz

Thanks, I will check back tomorrow.

johnpoz

@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.253

Now 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

David01

@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.

johnpoz

@david01 no it is not directional, you would have to set that up if you wanted opt2 to create traffic to opt1..

David01

@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 )

johnpoz

@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..

David01

@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.