NAT 1:1 Port Forwarding Issue
I've setup a new IP block using NAT 1:1, to extend my current public server IP. I then added the IP Network (Tried as individual IP's as well) to Virtual IP and then added a NAT Port Forward to my WebPorts alias (80, 443, 21) which auto-adds the Firewall Rule. I enable logging on this rule and then do a port scan of the first public IP (*.10) port 80 and it is unreachable, but checking the Log shows it is allowing it through.
Does this mean something else on my server is blocking the port?
Screenshots of each area for further clarification below.
two possible solutions
- check that server don't have any firewalls on it, or if it has, does that allow http-traffic
- change your new ip-block proxy-arp to c-arp addresses(p-arp–> c-arp) and test again
Thanks for the reply. The server is currently running fine on it's base IP, and it has no other firewalls in place - iptables is turned off as well.
If I switch the IP block to CARP, I get the following error:
You must specify a CARP password that is shared between the two VHID members.
Sorry, we could not locate an interface with a matching subnet for 207.XXX.XX.8/29. Please add an ip in this subnet on a real interface.
Is there something else I need to setup first?
That vhid password is something you can madeup, but if your virtualip's aren't in the same subnet as the primary(first one told to pfsense), that is not going to work.
I'm sorry but then i'm clueless
Thanks for trying, I appreciate it. It looks like I may have to bite the bullet and pay there support staff the $250 to set it up for me. It's a bit steep so I'm really trying to avoid it. :-[
Your 1:1 should most likely be /32 not /29.
Thanks for your help guys, I found this post, http://forum.pfsense.org/index.php/topic,5253.msg31680.html#msg31680, which seems to be the exact instructions I was looking for.
EDIT: scratch that, I thought I was pinging externally, but it turns out all I could get was internal pings. The IP's still do not route to my server box. Back to square one I guess.
Check packet captures on the VIP on WAN, if you don't see it there it's an upstream issue (possibly ARP cache upstream that needs cleared). If you do see it there, switch to LAN on the internal IP, see if it's leaving LAN, if it's getting a response.