Multiple IP's / Firewalls
I have a question. I am in the process of setting up a second IP on my WAN. I have been using a USG 3P for the last couple of years, but that unit doesn't support multiple WAN Ip's in the GUI, and configuring the jason file is unreliable and out of my knowledge base.
So I added a small switch before the USG and then added a PFsense on the other side and put in the second IP. Eventually, I am going to want to move both IPs to the PFSENSE and get rid of the USG, for simplicity among other things. But I have a question about getting traffic through the PFSENSE box to the same LAN addresses I have on the USG.
Traffic comes in on either of the WAN IPs. One goes to the USG, one to the PFSENSE. Then the traffic goes to the same switch and then out to my devices.
I am unsure if the traffic that comes out of the PFSENSE then has to go into the USG and out. The reason I ask, is I have set up NAT on the pFSENSE to a web server, but it is not reaching that web server, even though I believe the NAT and rules are set up correctly to forward the traffic to the internal webserver. So I started thinking maybe stuff comes in the PFSENSE, goes out, hits the LAN, then is sent back to the USG to be routed back through the USG to go to the device.
Can someone help me get the packet flow down in a situation like this? I figured the PFSENSE box would just forward the packets to the IP, not even thinking it might want to go through the USG.
The web server will send responses to the default gateway. So if the USG is set as default gateway response packets will not be returned to pfSense and you will have an asymmetric routing issue which breaks TCP connections.
You can either set pfSense as default gateway on the web server and some other devices you want to use it, or you have to do SNAT on packets going to theme, so that pfSense traslates the source IP into its own LAN IP (masquerading). However, consequently you're not able to determine the real source IPs of accesses on these devices, which may be desireable though on web servers and alike.