Look at the states to your ata device.

Build a firewall rule on the WAN tab with your SIP server as the source and your ATA/VOIP device LAN address as the destination.
Your ports may vary especially if your SIP server also does your actual RTP streams

SIPrule.jpg
SIPrule.jpg_thumb

MAC addresses don't exist on external (Internet) connections

Actually, they might, depending on what's on the other side of the router.  Any "broadcast" type connection would use MAC addresses.  On the other hand, point to point links might not.

@firewire:

Squid is configured in NOT transparent mode, because, with bridge, Squid seems  that does not work in Transparent mode.

In case the OP is still alive, see this (Comment #5) https://redmine.pfsense.org/issues/1620#note-5 ; test with that line modified accordingly and report back. (Needs to be tested with 2.3.x, noone will ever fix anything for 2.2.x and the PBI crap.)

And if you don't want the filter rule generated turn it off here:


thank you for the reply

the blacked out ip is the external client ip.  The visible ip is the server behind pfsense.

The wireshark was taken directly from the server.

I'll come back later with more packet captures from the client side and pfsense wan.

problem "solved". I have changed the default gateway on the sandbox to the ip of our analyzing system and added the following iptables rule:

iptables -t nat -A PREROUTING -s sandbox_ip ! -d analyzing_ip -p tcp -m tcp –dport specific_port -j DNAT --to-destination analyzing_ip

"So if you can, you may correct the guide"

Correct the guide how.. There is nothing wrong with it.

Ok, thanks. I do know about subnets, at least enough to choose masks properly to set up a 10.x.x.x network, with different kinds of devices on the different subnets (we had four at a broadcast facility I worked at). I thought perhaps Pfsense might had some sort of exception handling mechanism to treat specific requests differently.

The purpose of this project is to duplicate a manufacturing system we have (for testing purposes), with many unusual sensors and process controllers on one subnet, and the office LAN on the other. It's been proving to have some difficult lessons for me.

You might want to go to Hybrid on your NAT/outbound….

@phil.davis:

If the Peplink port forwards are working then the pfSense WAN will be receiving packets with destination pfSense WAN IP 172.16.1.2 - you can check that with packet capture.
Then it should just be a port forward from pfSense WAN IP 172.16.1.2 to the inside server 10.0.1.xxx - I don't think there are any special tricks with that.
But make sure not to have "Block private networks" checked on the WAN interface.

I am going to implement the same idea with Pfsense and Peplink 710.

I will let you know what the result is.

If already have the solution, please post it.

Thanks.

You would normally do such a thing with a proxy that users auth too.

If I had to do in this way:

I would still have the Internet service on the LAN?

Thanks

Bye

Your NAT and rule looks ok.  Get rid of those last two rules on WAN.  Non-floating rules are processed top-down, first-match so that block on the end will never get triggered, and you don't definitely want the Allow Any rule above it.  All your other NATs seem to work ok?  Do you know for sure that the NAT'd server accepts connections?  When in doubt, use the built-in pfSense packet capture to sniff on LAN (filtered by the .101 server) and see if traffic is getting past the firewall.  You can also sniff the WAN for rely traffic back to the external client.

There is nothing saying you have to use pfsense as dns… But you do no need to use a dns that will resolve the fqdn your asking about to your rfc1918 address.  This could be your AD dns, this could be bind running on some other box on your network, etc.

If your clients are using say googledns or some other public dns - then no split dns would not work would it ;) Public dns is not going to return your rfc1918 address, and if it did - then that would be a rebinding attack normally.. And not a good idea.

@Derelict:

Under
Advanced System Settings
, a field is available called
Public IP Override
. Any address put into that field will be pasted into the
address SIP field

Did you do this?

No. Pass rules do not log unless you explicitly enable that on the rule.

Again, that shows good two-way SIP initiated by the Phone IP followed by OUTBOUND traffic to the Phone IP on ports 7076 and 7077. That will have to be passed at the Phone IP side.

Welp, I set that field to my WAN IP and now it's working.  Thank you!

Limiters + NAT is fixed in 2.4.