Port fowarding and keeping source IP
-
I don't know if I am missing something obvious, but I've set up an IRC server using port forwarding and NAT reflection.
This is all working perfectly. However to use the banning features of the IRC server I really need that packets received have the clients source IP. Not changed the firewall. 1:1 isn't really an option. Is this possible through the pfSense interface at all?
-
Are you talking from clients on your lan nat reflection, or clients outside pfsense?
Why are you using nat reflection for clients on the lan side of pfsense - why not just connect to the irc lan IP directly, have pfsense dns or whatever dns your clients are using resolve the irc fqdn to its local lan IP? Then you can ban whatever you want. Inbound traffic from the wan would always list their public source IP in the traffic. Only doing something with nat reflection might show the pfsense IP.
-
It is a preference of the setup we have. We keep our externally accessible services uniform so all clients whether internal or external get routed the same. Basically no internal shortcutting.
And there is web resources available the IRC FQDN which would normally pass through our squid proxy for internal and external clients, and then passed to internal connections, but we'll now have to set up the web resources and SSL certs directly on the IRC box rather than our web servers.
Fair enough if pfsense doesn't allow this with NAT reflection, we'll just have to deal with it.
-
Sounds like you might be using nat reflection + proxy if your getting the pfsense IP?
-
Sounds to me like you want option 2 from:
https://doc.pfsense.org/index.php/Why_can't_I_access_forwarded_ports_on_my_WAN_IP_from_my_LAN/OPTx_networks%3F
You still use the FQDN no matter if external or internal, but it gets resolved differently.
-
where you could have a problem is box sends traffic to public IP.. But if you don't get pfsense lan IP, and original IP - server would just send back traffic via local network and not back out through pfsense and clients don't normally like responses from IPs they didn't send too, etc..
So unless your client is on different local network than server you run into asynchronous path/routing issue.
There should be no reason why your client can not just resolve these boxes to their internal IP and now you don't have to worry about reflection. I just really don't see a need for nat reflection in a network correctly using name resolution.
