Port Forward Green to Red - Prevent Everything Else

Tried searching through the forum, but cannot seem to find an answer to this one.

I recently came across IPFire and feel like it may be a good solution for me. I’m connecting a trusted network (setup as the Green network) to an untrusted network (setup as the Red network). The goal is to forward ModbusTCP requests from Green network to the Red network, but prevent any Red to Green packets (save what is required for ModbusTCP to supply a response packet from Red to Green).

Network Layout:

  • Green Network: 172.16.1.xxx
  • Red Network: 10.1.xxx.xxx
  • Green Network ModbusTCP request client: 172.16.1.79/255.255.255.0
  • IPFire Green Network IP: 172.16.1.80/255.255.255.0
  • IPFire Red Network IP: 10.1.3.1/255.255.0.0
  • Red Network ModbusTCP host: 10.1.2.1:502/255.255.0.0

In Summary:

  1. ModbusTCP request made from source 172.16.1.79 to IPFire at 172.16.1.80:502
  2. IPFire forwards ModbusTCP request to actual server on Red network at 10.1.2.1:502
  3. Red network server receives ModbusTCP request, replies to IPFire at 10.1.3.1
  4. IPFire returns ModbusTCP reply to source at 172.16.1.79
  5. All other communications attempts from Red network to Green should be prevented by firewall

Seems like I could use the Port-Forwarding how-to, but with Green and Red reversed. However I’ve tried a few different combinations and it does not work. Additionally I cannot ping the Red network’s ModbusTCP server from within IPFire (ie ssh’ing into IPFire), nor are there any log entries for any of this on IPFire in any of the logs it keeps.

Thank you kindly for the help.

MT

Not sure what your doing there.
But
Ipfire has red address
Green is network with server requesting TCP modbus.
A return response from device in red should be allowed by default
If initiated by someone in green

If modbus from red is trying to go to server without a request than you will need a port forward.

@mt_onsemi , welcome to our community.

Do you know the wiki article about default FW settings?

Traffic from GREEN to RED ( LAN to WAN ) is allowed by default. Packets from this connections are passed without blocking.

  • ModbusTCP client sends to ModbusTCP server
  • IPFire establishes the connection and remembers the tuple ( clientIP:clientport, serverIP:serverport, connectionport )
  • ModbusTCP server sends reply to ModbusTCP client ( to be exactly serverIP:serverport → IPFire:connectionport )
  • IPFire forwards the packet ( serverIP:serverport → clientIP:clientport )

So it isn’t necessary to define portforwarding rules.
If you want that this connection is allowed exclusiv, you need an allow rule ( clientIP:clientport → serverIP:serverport ) and a deny rule ( GREEN net → WAN ).

@hvacguy
Clearly not doing what I need :slight_smile: . I’m trying to prevent all access from Red network to Green Network, but do allow ModbusTCP traffic (on port 502) through from Green to Red, and then any replies from Red to Green. Should also allow ping requests from Green to Red and back. Other than that, nothing.

@bbitsch
I did see that article, and figured things should just work but they are not. In my attempt at getting it to work, it’s entirely possible I changed a setting that shouldn’t be. Here’s a list of settings that, to me, appear to be set correctly but perhaps my understanding of the associated help pages is wrong and thus the setting is incorrect…?

1 Like

this is default firewall behavior.

again default behavior ok.

again default behavior.
so long at communication was initiated from green it can respond ok

This with recent updates is blocked Not 100% sure.
may need to allow ping with a firewall rule.

1 Like

If the ping is initiated by client in LAN, this is default behaviour also.
Pings from server in WAN ( red network ) to LAN client are blocked by default.

1 Like

Thank you both for the confirmations of my suspicions, there must be something else amiss (perhaps hardware) that I’ll need to dig into. Funny thing is I connected Red network ethernet directly to a laptop and was able to ping the ModbusTCP server on the Red network, so feel like it’s not hardware. More troubleshooting is in my future it looks like.

Additional relevant information is there is another 10.1.xxx.xxx network, so this IPFire must do port forwarding rather than serve as a gateway from Green to Red lest there are two gateways to two different 10.1.xxx.xxx networks.

Pinging is now working (swapping out an ethernet cable that sometimes was making connection and sometimes not).

However, I’m still unable to determine from the various Wiki pages how to do port forwarding from green to red. I’ll attempt to rephrase my earlier message in the hopes it adds some clarity.

Any number of computers behind the firewall, in the green network, should be able to request ModbusTCP from the firewall’s green network IP address. The firewall will then port forward that request to a designated red network computer and return any replies. I cannot use IPFire as a gateway in this case, and I believe I need port forwarding from green network to red, since the red network is on the 10.1.xxx.xxx address space and that address space already exists behind another gateway on the green network.

The goal is to only allow ModbusTCP (ie port 502) from green network computers to red. Everything else would be locked down. This setup is common when two companies wish to share process control information from PLCs that are on their respective networks, but do not want to expose their PLCs or the PLC network to the other party.

Thank you kindly for your help,
M

As stated by @bbitsch before, If you do not have some specific rule (e.g. blocking connections in the green network not directed to the proxy) everything should work by default. Port forward is necessary only when you have a connection initiating from the red network side. Of course, your network configuration should also work outside IPFire behavior. If you have a faulty switch or cable, or your servers are not correctly configured, what you want to do will not work, but not because IPFire.

1 Like

@mt_onsemi Did you add a gateway (ipfire red interface ip) to your modbus device?
What says your firewall log?

2 Likes

@mt_onsemi Could you please specify your setup in more detail?
Can be a picture or just a description in text. Do not forget connections between the several networks.
So we can help you more efficient.

Regards,
Bernhard

3 Likes

From your reply #4 above you have the default setting for Outgoing connections which is that everything is allowed.

With this default setting you don’t need to do any port forwarding or firewall rule settings to have green computers be able to access anything on the internet via the red interface.

I had a google about ModbusTCP as I didn’t know anything about it before this morning. This limited investigation indicates that it might be the case that any reply from another ModbusTCP based system is not considered part of the same TCP communication but a new connection. If this is the case then you would need to create a Port Forward rule from the red interface to the green IP’s that need to be communicated to.

You indicated that

As this address space is a private non routable address this must mean that you have another router between your IPFire and the internet. In this case any port forward rule from the red interface to green interface on your IPFire system has to also be duplicated on that other firewall/router.

In my reading up about the ModbusTCP protocol I also found several entries that indicated that using Port Forwarding with ModbusTCP is not an advisable route. Below is one comment I found.

Modbus Security Summary

While Modbus is an excellent ICS protocol, it was created before security was a consideration. As a result, it currently has no capability for authentication or authorization control. Any device with a network connection to a Modbus controller can potentially change any of the controller’s I/O points or register values. Many controllers can even be reset, disabled, or loaded with new logic or firmware code.

Most of the results I found that mentioned the security weakness of using port forwarding with ModbusTCP said that the advisable route was to set up a VPN tunnel between the various locations and use that for the ModbusTCP communication. No port forwarding required and no unsecured exposure of your PLC systems.

If the above is not correct then as @bbitsch and others have said you need to give more details about exactly how your network is constructed so we can better understand.

4 Likes

@svenf
The IPFire firewall log is empty throughout all the port-forwarding attempts. I did ssh into IPFire and listed out open ports, and noticed no green network port 502 was open despite being configured for “Green…Firewall:502 → 10.1.2.1:502”.

@svenf
While I may be mistaken, I do not believe a gateway is needed (ipfire red interface ip) since there is no access required on the red network to any other networks. It is just the IPFire red interface and the ModbusTCP server’s interface. An ethernet-to-fiber-to-ethernet bridge connects those two, and that’s the entire network.

@bbitsch
Here’s a quick and dirtly network diagram, hoping this helps.

@bonnietwin
ModbusTCP is indeed not very secure, but the internet isn’t involved here so security concerns are reduced. Additionally, the entire reason for using IPFire was to isolate all traffic between the red network and the green network, save for port 502 (for ModbusTCP). Using a VPN in this situation would probably work, but since there’s no internet or any other network between the IPFire red interface and the ModbusTCP Server interface I felt it was unneeded. In addition, a firewall would then still be required because we do not trust the red network ModbusTCP server…other than it’s port 502 that provides Modbus protocol.

@mt_onsemi ,
Why does your client send his requests to IPFire and not just to the server 10.1.2.1?
If all connections client <—> server are initiated by the client you do not need any special rules.
This is the standard case ‘client in LAN sends request to server in WAN’.
If there are situations, where the server initiates the connection, you just need a port forward rule to allow this dedicated packets. Sorry, didn’t look in the ModbusTCP protocol, yet. So this statement isn’t really specific.

The IPFire firewall log is empty throughout all the port-forwarding attempts

You need to activate the logging for each firewall rule. If it activate and the log is empty, then there is no traffic.

While I may be mistaken, I do not believe a gateway is needed

If you want communicate between to subnets you need routes and gateways.
Your client sends modbus request from 172.16.1.80 to 10.1.2.1. The client knows only his own subnet and can directly communicate with them. For all other subnets it needs a route or a default gateway. The same for your modbus server.

At first disable all filewall rules and open firewall for free communication.
2 ways for you:

  1. Adds the firewall ip as route or default gateway to both devices. Finished
  2. with NAT: You need only to add a route or default gateway in your client. You add a firewall rule with source NAT. The firewall replace the client ip (green) with her red ip for all incoming traffic from client.

If you dont want routes or a default gateway, then you need double (source + dest.) NAT. I dont know how to configure it in ipfire.

IPFire makes NAT out of the box!

request: (clientIP:Sport, ServerIP:Dport) ---> (IPFireIP:Iport, serverIP:Dport) 
answer:  (serverIP:Dport, IPFireIP:Iport) ---> (serverIP:Dport, clientIP:Sport)

To allow connection initiated by the server a port forward rule

(serverIP:Dport) ---> (clientIP:Sport)

is necessary.

see wiki