https://forum.pfsense.org/index.php?topic=82732.msg453269#msg453269

Thanks guys. I kinda figured that I was attempting something not doable. Kinda glad too, 'cause if it were possible I would have had to completely rethink what I think I know about IP. I hate to use up public IPs just so I can occasionally get to these hosts (rarely used management PCs) so I guess a VPN is the way I'll go. Thanks for the input.

most likely the same as last time..  did you go through the troubleshooting doc? https://doc.pfsense.org/index.php/Port_Forward_Troubleshooting

@cmb: Where you see nothing at all for that IP in a packet capture on WAN, not even ARP requests, it's a problem with your modem most often with cable, otherwise something to do with your ISP. If the VIP weren't actually configured or triggering an ARP response for some reason, you'd see repeated incoming ARP requests on WAN "who has x.x.x.x" for the IP in question, with no replies, when you're sending traffic in from the Internet to that destination IP. No point in digging into the VIP when there is nothing at all for that IP on WAN, as you know 100% for sure the problem is upstream. Hello Community, I know this is an almost a year old thread but we never got it resolved unfortunately. As cmb suggested, it might have been an issue with the provider's modem but we were able however to test these IP addresses when connected directly to Comcast modem and all of them worked fine. As opposite to what we can use on pfsense: Here is a list of which IPs work and which doesn't: xx.xx.xx.241/28 - pfsense WAN xx.xx.xx.242/28 - WORKS xx.xx.xx.243/28 - DOESN'T WORK xx.xx.xx.244/28 - WORKS xx.xx.xx.245/28 - DOESN'T WORK xx.xx.xx.246/28 - DOESN'T WORK xx.xx.xx.247/28 - DOESN'T WORK xx.xx.xx.248/28 - DOESN'T WORK xx.xx.xx.249/28 - WORKS xx.xx.xx.250/28 - WORKS xx.xx.xx.251/28 - WORKS xx.xx.xx.252/28 - WORKS xx.xx.xx.253/28 - DOESN'T WORK xx.xx.xx.254/28 - Comcast Gateway As stated above, there is no incoming packets when checked by Packet capture. Every IP is an separate entry on Virtual IPs tab - this seems to be correct for another subnet we have with different provider. What else could I try checking?

Thanks for your pointers everyone. Everything is working fine now.

It works the same for LAN to LAN (assuming that's two diff LANs, say LAN to LAN2) as for LAN to WAN. NAT just generally doesn't happen (no match where it's processing that) going from LAN to LAN.

Very true….  But I still don't feel right pulling the actual trigger on a suicide..

Question: Which two of the three external IPs you've posted should map to 192.168.0.46 and 192.168.0.51 respectively? So you say when you browse to https://192.168.0.46 and https://196.168.0.51 internally, the pages load correctly? Is this right? I think it may help a lot if you post your NAT and firewall forwarding rules for your WAN interface. Screenshots, please - not ASCII.

But its still an abomination if you ask me ;)  And be it a huge performance hit doesn't change the fact that its not optimal, why send traffic through or even to my firewall/router that is just going to a box sitting next to me on my own lan.. I can not think of a reason where someone would say, yeah nat reflection is the best way to do this.. I see it as a work around for bad design choices sure.

In passive conection servers says come talk to me on port x http://slacksite.com/other/ftp.html So u have to forward those ports But from what u were showing its not even making a control connection

Excellent.

Solved! Interface: LAN Protocol: TCP Source: Any Destination Port Range: HTTP Redirect port range: 192.168.2.1 (Debian) Redirect target port: 80

@Derelict: So you didn't enter a VIP in Firewall > Virtual IPs you just selected other and entered it there? Learn something new every day. Didn't know you could just enter an arbitrary address there. Good to know. Yes, that's it. Hard to explain… because it expects a network and I entered an IP (/32)... Packets matching this rule will be mapped to the IP address given here. To apply this rule to a different IP address than the IP address of the interface chosen above, select it here (Virtual IP addresses need to be defined on the interface first) Regards!

And the answer in my case was setting the modem in bridge mode. For KD customers it's a fairly simple online activation process. Now my pfSense's WAN gets the public IP directly.

SOLVED.  Thanks.

Hi! Thanks the answer. So.. I ty again… Two type of sites are. One is DSL line they connected via public internet acces to vpn servers. The second is connect via Middle Aera Network (multi sites connected via wlan) to vpn servers. first pf-sense handle the database connection from sites. the second pf-sense handle the file related connections from sites. the first pf-sense have 2 internet connection, a MAN connection and several internal lan connection. The second pf-sense have a very fast internet connection, a connection to first pf sense and a connection to file servers. The MAN sites can't connect the internet only tough the first pf-sense. all sites must be connected both of PfSense. but the MAN sites can it only trough the first PfSense (that hande the MAN network). so the MAN network can't routing the second pf-sense's network, so the MAN sites can't reach them. Therefore the VPNs destination is the first PfSense's MAN interface. the first PfSense forwarding the port to second PfSense. The problem is, the second PfSense's response to MAN sites go trough the first PfSense but the first PfSense not translate the output packet source address to MAN interface's IP adress. The packet go trough the first PfS and go to a network than can't handle the second PfS IP address. therefore the MAN sites can't build the VPN connection. The diagram only the structure not showing the problem.