@luke240778:

Thanks for the reply, but dont understand fully.  Are you saying not to do a 1:1 and just port forward public ip:80 to local ip:9080 ?

You can keep the 1:1 and add a port forward to do just that, the port forward will override the 1:1 for traffic matching it (otherwise dest port 80 would go to dest port 80).

Answered my own question by flipping through the NAT portion of The Book.

All that is needed is to enable NAT reflection, which is disabled by default.

And the DNS solution I have used in the past is called "split DNS". But if you can set up a proper DMZ using external addresses, this is a non-problem.

LAN rules have nothing to do with communicating WAN side to LAN side, that's WAN rules. You didn't mention if you added the required static route on 1.1, guessing you're still missing that.

Just to finish this thread, I managed to solve this problem with help from my phone device manufacturer.
It turns out there was a mismatch between the firmware version on my device and the sip platform that my provider uses.
It appeared to be something very small that caused the provider to think there was no response from my end.

So, in the end, it wasn't related to pfsense at all.

Solved.

i somehow got it to work using NAT 1:1 to map specific internal address to the outbound address on the interface i want based on destination network. it seems more like a walkaround and not really elegant.

Brain fart! Got it to work. Its the source port that should be 20. Not the destination port.

If your DNS server really does require NAT reflection, it won't work. NAT reflection is broken for UDP, and has been for years. (Check redmine.pfsense.org)

That is awesome!!! I adjusted it within the specific port forward and it is now working.

Thanks very much for such quick and CORRECT advise :)

Stu

Yes I understand but how do I combine both outbound NAT and port forward for the same packet ?

Do I first create an outbound nat rule to convert src:10.1.1.30 dst:10.1.1.49 to src:192.168.1.13 dst:10.1.1.49
and then add a port forward for 10.1.1.49 to 192.168.1.91 ?

What would the way of doing this and what interface would the NAT/PF rules be on INT, EXT ?

And how would the incoming packet be natted, would it be the same in reverse or would I need to configure new nat rules for this ?

Sorry if this is basic stuff but I am completely new to pfSense way of doing nat (and to be truthful the documentation does not help much).

Thanks

The window size and scale factor is set by the source host, you can't change that. That's unlikely to be relevant.

Port forwards don't rewrite source ports. There isn't a difference network-wise between allowing traffic in from the Internet on 1:1 and rdr (port forward). Either way you're strictly rewriting the destination IP (though with rdr you can rewrite the destination port that's only if it's diff outside vs. inside, eg from the Internet you have a web server listening on port 8000 but it's on 80 internally, that doesn't sound like it's the case here, and wouldn't be relevant either way). That's different for outbound traffic but that's not what you're looking at here.

@chpalmer:

Looks right.

Try changing your virtual IP to alias…

Other should be fine but the change may jar things...

http://doc.pfsense.org/index.php?title=What_are_Virtual_IP_Addresses%3F

this did it.  Thanks.

no, works fine. not enough info there to provide any suggestions, aside from check the usual:
http://doc.pfsense.org/index.php/Port_Forward_Troubleshooting

Hmmm I looked at the HAproxy package a while ago for pfsense but saw no way to configure it as a reverse proxy with a single front end and multiple back ends based on a URI, at least in the pfsense UI.

Is there a way to change the configuration on the CLI or somewhere else I'm missing to do this?

sorry if i didnt make it clear, ill try again

The application will consult on the database information, just it.
Then it will go trough the pfsense and then pfsense will redirect to the databases on the other side.

i just aks if pfsense can redirect to more than 1 ip on the same port.

For IP aliases you can use either /32 or the actual mask on that network, doesn't matter either way if there is another IP on that subnet on the system. If that's the only IP in that subnet on the system, then it must have the actual mask you're using for that network.

Just wanted to follow up here for others who may want to know the cause, rwoo bought support and we walked through everything. 3 separate main issues here.

The VIP on WAN was conflicting with another device. Turning the packet capture on WAN up to "Full" detail and checking the destination MAC address showed that. That's a good thing to keep in mind when troubleshooting things along these lines, seeing something in a packet capture on WAN doesn't necessarily mean it's being directed to the firewall, if the destination MAC isn't the firewall's (i.e. you have an IP conflict), then it isn't going to pick up that traffic and forward it. The DMZ server's default gateway was wrong. the host firewall on the DMZ server was blocking off-subnet traffic, so you could browse to it from the same subnet, but not from any other network.

Took care of those and it's all working.

well I didn't actually match them up but I see ftp packets out of your lan interface re0

11:01:19.581950 IP pool-173-57-104-76.dllstx.fios.verizon.net.62942 > 192.168.1.119.ftp:

So its forwarding the packets.. So if your ftp server is not seeing it, then its not pfsense fault

I posted up the easy thing to do for tcpdump..  So you don't see all that other noise, just ftp.  And vs the name resolution you just get IPs

tcpdump -i 4 -n -q port 21

-i 4 or -i 3 is my index of my interfaces - you can use either name or index, I used index.. You can view your index off of tcpdump -D

example

tcpdump -D
1.gif0
2.ovpns1
3.vmx3f0
4.vmx3f1
5.lo0

I can look a bit deeper, but I see packets on your lan interface going to your ftp server on port 21..   But I did not see any response - so that tells me either your ftp server never saw the packets, or he is not answering.

In my lan sniff you see the server answer back
07:08:34.396528 IP 192.168.1.4.21 > 173.236.157.143.19998: tcp 0

I don't see anything coming from ftp back – so its not getting the packets your putting on the lan interface of your pfsense, or its just not listening on 21, or it has a firewall blocking? But clearly you can see from your sniff of your re0 that packets to ftp on 21 were put on the wire.  So pfsense did what you told it to do, forward the packets to that IP on its lan interface.

Looked like it was working to me..
-I can connect from LAN with dyndns adress (my.domain.com) with active, but NOT passive connections.
-I can connect from LAN with dyndns adress (my.domain.com) with passive AND active connections.

So now what your telling me its a requirement that you have to use passive from the internet and the lan both?

Why not just leave the helper and set your profile to use active connection?  If you at some location that it does not work then change it to passive.

Or why don't you just go back to smoothwall ;)

If you would setup your local dns to resolve that fqdn to your private IP you would not have any issues.  You could still use the fqdn be it inside or outside.