Thank you!

It is incredibly helpful getting re-pointed when feeling stuck in the middle of a problem.
And overlooking what should have been an obvious cause. (Trees for the woods etc).  :)

Confirmed packets were going to PBX and I had completely missed the integrated firewall.

Silly mistake, but hopefully this may help another.

Thanks Again.

Ok, you're right. I will keep them in one topic for future problems. I don't think I can merge them myself.
Any idea how I can solve the NAT problem?

@boss_001:

If i want to use vip, what type do i use and how do i make roules in the firewall and/or outgooing NAT?

Type  ?
IP Alias, CARP, Proxy ARP or Other?

Depends on your situation. Usually IP alias.
https://doc.pfsense.org/index.php/What_are_Virtual_IP_Addresses

Found the solution in this topic : https://forum.pfsense.org/index.php?topic=43507.msg225529;topicseen#msg225529

Found the solution in this topic : https://forum.pfsense.org/index.php?topic=43507.msg225529;topicseen#msg225529

So the packets don't reach your WAN interface obviously and it will not be a pfSense issue.

You were both right on the money and after disabling the default rfc1918 rule I'm up and running.  Thanks!

This was a Elastix issue and not related to pfSense. Mods can close/delete thread.

That list covers just about everything it could be.

You'll probably have to start looking at packet captures to see where you went wrong.

your dest shoudl be 22.. Agreed you don't know what port the traffic will come form.. But you do know it will be going to 22..

@johnpoz:

All you need to do for this is simple port forward, clickity clickity done..  It will auto create the firewall rule for you - the only thing you might have to do is move the rule up the wan list if you had something that would block it.

Forward your ports 80 and 443 to whatever IP 192.168.1.25

Then test from outside.  If no work then check the troubleshooting doc https://doc.pfsense.org/index.php/Port_Forward_Troubleshooting

And by that, do you mean create the PF under the NAT Tab? If so, I already tried that and had no luck. Is there anything that I need to setup extra on my IIS Server?

EDIT: Added screen shot of Port Forward rule: https://postimg.org/image/wbsh0fs3r/

Thank admin,

This is my config, IT's WORK !

Steps:
#1/ FIREWALL->NAT 1:1

#2/ FIREWALL->NAT OUTBOUND:

#3/ FIREWALL->RULES->WAN:

"So can pfSense do port forwarding if it's dhcp service is disabled"

What would dhcp have to do with port forwarding.. So yeah…

As to just working - that would be pfsense..  A port forward is really clickity clickity 10 seconds to accomplish.. Have you gone over the troubleshooting guide?

https://doc.pfsense.org/index.php/Port_Forward_Troubleshooting

How is it you have wasted days on this??  Port forwarding even troubleshooting to find your mistakes takes all of a couple of minutes.  Does the traffic hit your wan?  Sniff, does it leave your lan headed to where you wanted to forward it?  Does it get an answer back..

Do you devices have internet through pfsense?  Or is pfsense not even their gateway?

To be honest that would be a really really bad choice for a "cheap" camera.. Passive would be a much better choice to have less problems with.

Does the camera have sftp support, this would be a much better option to be honest, its only 1 port normally 22 and its SECURE..

Hi there,

I just ran some test.

I tried the same thing from SRV2 to SRV1 and it's working.

Any idea why it is not working from SRV1 ?

Thanks, you were right.
I made a mistake with picture, in the gateway and static route, the gateway for network 1.0 is 1.10

nat_rule.png
nat_rule.png_thumb
gw.png
gw.png_thumb
staRoutes.png
staRoutes.png_thumb

I had to open a support ticket to get this fixed.  Here is the reply from the technician:

–-----

Upon my initial reading here is what I think is happening:

Inbound connection arrives on pf2:WAN3
pf2 forwards the connection to the internal host
The internal host replies but its default gateway should be the LAN interface's CARP VIP which is currently on pf1
pf1 does not know what to do with the traffic so it is dropped.

The typical work around for this would be an outbound NAT entry on LAN so all traffic going to the inside host appears to come from the interface address on LAN. That will make the reply traffic same-subnet so the default gateway in the target host will not need to be used.

The downside is you lose the ability to see the actual outside source addresses in the logs/connections on the inside host. This might or might not be important to you.

This turned out to be exactly the problem.  Adding an "outbound NAT" entry solved this.

Ok, that would be if you had some kind of stateless ACL filtering in place on a routing device of some sort that isn't doing NAT. If you have the default LAN rule in place, that suffices for what they're asking for in the NAT context.