I figured it out. My 1:1 NAT rule for 192.168.230.8 had NAT Reflection set to Enabled, whereas the 1:1 NAT rule for 192.168.230.190 has NAT Reflect set to System Default. As soon as I switched it to Enabled, things started working. :)

Some mornings it's just not worth getting out of bed. Thanks to both of you, I have it working.

Gerald

@Derelict:

Yeah that's not at all how it works. Put your VIP and outbound NAT rule on the outbound interface. OPT2 in this case if I am understanding correctly.

Thank you! That worked perfectly first time - after all this time of banging my head. In case anyone else is looking, this is what I did:

1. Set up a virtual IP of type "IP alias" (but perhaps some other types would have worked just as well) with the IP that I want the packet to look like it came from (192.168.2.10 in this example). The IP alias is set on the interface it will leave the router on, not the one it arrives into the router at (OPT2 in this example).

2. Set hybrid NAT (or if you prefer Manual/AON) and then add an Outbound NAT rule again on the same interface the packet will leave on (OPT2) with source = any (or whatever IP range the packet actually came from) and dest = the destination IP or its subnet or whatever (I used 192.168.2.0/24). Then set the translation address by choosing the virtual IP from step 1, in the drop-down box.

As far as I understand it in lay-terms, the misunderstanding is that outbound NAT seems to mean "outbound from the router", not "outbound from a given network into the router". Ambiguity of language, but what a headache. The packet, sent to its destination IP, travels in from OPT1 and is picked up by NAT when it's outgoing at OPT2 (the interface in the NAT rule). As the packet's src matches "any" and its dest matches the value entered in the NAT rule (192.168.2.0/24), its source is translated to be 192.168.2.10 as required.

Packet capture confirms it - when I ping as described in the 1st post, packet capture on the OPT1 interface shows a ping and reply from 192.168.1.2 -> 192.168.2.2, but packet capture on the OPT2 interface shows a ping and reply from 192.168.2.10 -> 192.168.2.2 as desired.

Thank you very much indeed. (Maybe this could be made clearer in the documentation as well?)

Pretty sure that NAT will have to be done on the other side.

BINAT in a phase 2 translates the network on your side as it appears to the other side. You would set up a Phase 2 for 10.2.0.0/16 to 10.3.0.0/16. They would NAT it from 10.3.0.0/16 to 10.1.0.0/16.

Here's a more appropriate link.

https://forum.pfsense.org/index.php?action=search&advanced&search=Please%20match%20%20the%20requested%20format&sort=id_msg%7Cdesc;

Hi there,
it seems that this error is caused because the same source (128.140.150.200:5060) is sending packets to two different ports.

I've asked IPDirections to start the communication directly on 65002, which means all communication from port 128.140.150.200:5060 is send to 65002. That did the trick, now all packets gets through to my PBX.
For me this issue is solved with a workaround, however I still believe  this is an pfsense/FreeBSD issue.

Many thanks for assistance!

Chris

Depending on what you're using for internal DNS, you would either create a new zone for your external domain and then just add some A records to it that point to your internal servers local addresses.  If you're using pfSense then you can just add a couple of host overrides.

What does that have to do with using pfsense with a bridge.. So you can not run speedtest from your client that your currently connected too.  I don't understand how pfsense be it in a normal nat routing setup or a bridge setup tells you how much bandwidth your ISP is giving you??  Sure you can see how fast a client is pulling/pushing packets to your isp and beyond.  But you can do that on the client as well.

Here let me help you out
http://speedtest.net
http://speedof.me/
https://www.verizon.com/speedtest/
http://www.att.com/speedtest/
https://www.speakeasy.net/speedtest/
http://www.dslreports.com/speedtest

many many more..

Extra info:

We have tested this again.
When calling trough the site-to-site VPN connection everything goes well.

@Derelict:

#5 on this list: https://doc.pfsense.org/index.php/Port_Forward_Troubleshooting

Agreed, I just never thought it would be used by them for device control and I haven't always had the wireless receivers, and 443 has worked for me in the past.

So…

After rebooting the firewall, looks like the issue has fixed itself.  If I had to take a guess, even with the process restarts and the session tables being cleared, it was not applying the NAT to the running configs.  Guess my concerns is that I'd have to take an outage like this for changing advanced NAT settings, which shouldn't be an issue in a home environment.  Thread can probably be closed, unless someone would like to discuss.

-Tom

Hi,

the IPs on both sides happen to use the same subnet, so I need to NAT. But you were absolutely right about the cause. But it does not help me as I am not using the WAN interface for the connection to the other network, so I cannot set the IP. I will try to switch to SSH, this will work for sure.

Thank you very much!

I created a new topic to isolate the network 192.168.10.0

https://forum.pfsense.org/index.php?topic=118803.0

^ very true!!  But highly unlikely you would want all your IPs on your wan sent to the same place ;)  So in that case you would prob use the dest of your specific vip you setup in that /28 network, etc.

@Derelict:

Dude, your firewall rule is disabled. That's why it's grayed out / translucent. Uncheck the Disable this rule checkbox.

ARRRGGGGHHH! That was the problem. I thought it was grayed out because it was automatically created.

Thanks!