Messages

Hi Meyergru,

The RTP port range is a bit larger than configured but yes it's correct.
I misswrite the oubound rule (now I corrected it) it's not .178 but .181.

I'll try the static port suggestion, but anyway on previous v22 I'm sure I necer used it as I'm pretty sure I never used the 1:1 NAT.

To describe better, when voice left my server and reach the provider something goes wrong. While I'm able to capture voice packets on the WAN interface, my provider seems not receiving them.
This have sense if something in NAT doees not works as epected and packets looks bad from provider's firewall point of view.

But understand what is wrong is hard.
Suggestion or opinion from others may help

Hello, I really hope someone may help in somethig is struggling me:

Unfortunately I had to reinstall some VM. I moved from an old ESXi 6.5 to ESXi 7u2 and I installed a new OPNsense VM from the scratch as my old v22 VM where damaged and I've not a backup.

Than OK There are many things that I could miss or that I could configured wrong, but something works really strange.

In brief I've a SIP server on an OPT network. I configured two port forward rules from one VirtualIP to the Server IP (one for SIP 5060 port, the other for voice RTP range 10000:65535)

They looks like:

WAN   TCP/UDP  VoIP_Auth    *   pub.pub.pub.181   5060 (SIP)    opt.opt.opt.181   5060 (SIP)
WAN   UDP         VoIP_Auth    *   pub.pub.pub.181   Ports_RTP     opt.opt.opt.181   Ports_RTP     


At the same time I have an Outbound NAT rule, to be sure that my server communicate thru the Public IP I use for incoming:

Interface   Source                    Src Port  Dest  Dst Port          NAT Address        NAT Port   Static Port      
WAN          opt.opt.opt.181/32        *         *     *           pub.pub.pub.181         *            NO


I'm pretty sure this setup worked on version 22 but I eperiencing a lot of problems in RTP audio from when I'm using the new installation v23.

After spending a lot of time and a lot of nights on this issue It seems related to something wrong in NAT operations.

First, from packet captures made on both WAN and OPT interfaces, I could decode audio streams and confirm that two-way audio is present.

Just to make everything complex, sometime (rarely) audio looks works (i.e 1 test call over 50 calls)


Anyway, after many other tests and nights I found that as soon as I create a 1:1 NAT rule like the followinig, Voice pass correctly.

Interface   External IP           Internal IP                Destination IP         
WAN          pub.pub.pub.181/32   opt.opt.opt.181            *               


My problem is that I'm not able to understand why Nat forward+Nat outbound does not works. It have no sense. It have no sense also because nothing strange  appear analyzing packets 
And, of course, using a NAT 1:1 introduce potential security risks.

In brief even if the signaling SIP works correctly, the voice sent from my internal server to the outside does not arrive if I did not introduce the NAT 1:1 rule.

Please help me.
Thanks

Hello,
V.23 looks more and more annoying. I could understand a new major version but I can't all differences I see from the old 22 configuration.

My old VOIP Inbound NAT tell to create a forward from UPD port range 1024-65535 to range 1024-65535.
Now I see that it seems no more supported. In v23 inbound nat did not allow for a destination port range.

Why? How should I configure it? 

I think I have a similar issue
I was trying to get access to the GUI of my modem following this tutorial post https://forum.opnsense.org/index.php?topic=8616.0

The problem is that when I try to create outbound NAT I don't see the virtual IP I defined as a drop down option under "Translation / target"

Hi Flash99,

Even if I've not found other reply I could say this:
It seems that new OPNsense v23 use Virtual IP only to know what additional IP one is configuring. The reason is not clear, but it means from one side that you have to write your public IP manually each time you have to create a rule (i.e NAT) and most important you have to be carefull about the subnet as OPNsense use /12 by default (that in my mind is a bug).

On the other side it means that if you load a previous backup older configurations looks like Virtual IP configured,but as soon as you try to edit, the Virtual IP is converted in a single address with /128 subnet (not good at all).

I'm facing a problem with NAT that I'm not able to understand and worst thing, packets capture did not catch  some legs packets. At the same time during few packet capture tests I made, Nat issue seems to disappear (like if the pcap driver bypass some things)

Anyway,  regarding your issue, It could be possible that your problems is related to returning packets:
You will contact your natted device using a NAt forward rule.
than if your OPNsense have it's WAN as 1.1.1.1 and you have a virtual ip ad 1.1.1.2, You have a rules that forward (incoming NAT) connections on 1.1.1.2 ssh port 22 to an internal private IP your device).
Well, when your device reach the internet and than when it reply to your connection attempt from the outside) it use the standard outbound rule. It means thet your device will reply being natted as 1.1.1.1 (OPNsense main WAN IP).

I may suppose that if you create an outbound NAT rule that tell OPNsense to NAT out your device private IP using the VirtualIP 1.1.1.2, It will work.

Hi Franco, Hi pmhausen,

I'm doing a comparison between 22 and 23 installation. Just to add more details, VirtualIP disappear also from the NAT destination drop-down menu.

As far as I know Virtual IP are used to tell OPNsense which additional IPs are managed by the firewall.
Until 22.1.7 VirtualIPs are also avaialble into configuration drop-down menu (like nat).

I undestand that I can use alias to see my virtual ip in version 23 drop-down menu but when, from what version, virtual IP are no more used as before?
Is there any changelog or other notice that highlight in possible problems while restoring a v22 configuration into a new v23 machine? (applying a /128 subnet looks as a bug).

At the moment I'm trying to reconfigure a v22 appliance and test if problems I'm facing disappear. I'll update you asap.

thanks



   

Hi Franco,

thanks for your reply.

I don't understand enaugh well what you mean.

In brief I done the following:
- I configured Virtual IPs so OPNsense is able to manage additional Public IPs assigned to my server (vmware VM).
- I configure NAT rules to forward incoming packets on specific ports to reach my DMZ servers.
- I configure Outbound rules to thell OPNsense to allow outbound packets from my DMZ servers to reach the internet using a specific VirtualIP address.

In version 22.x, When I configure outbound rules I can select into the "translation/target" drop down menu one of configured Virtual IPs.
In version 23.x, Virtual IP are no more present into the drop down menu.

When I imported my old backup into 23.x new installation, NAT outbound rules appear exactly teh same until I edit them. As soon as I edit a rule, "translation/target" IP is shown as the public IP address with a /128 subnet.

It is at least strange: Any possible changes between 22 and 23 versions should convert a Virtual IP into a  /32 IP. Also my public IP is a Class B Public IP, than a CIDR of 128 bit have no sense.

Can you please eplain better your reply?
Thanks
Sergio






 

   

Hello,
I'm sorry if what I'm writing is wrong, but unfortunately I had to rebuild a new OPNsense installation. I installed the following version:   OPNsense 23.1.1_2-amd64 - FreeBSD 13.1-RELEASE-p6 -OpenSSL 1.1.1t 7 Feb 2023

I'm struggling during the past days because some NAT (incoming and outgoing rules) does not works as on my old configuration. Unfortunately I've not the latest backup and than I spent time in checking my configuration.

Well today I notice something strange: Outgoing nat configuration not have anymore virtual IPs (that I had in version OPNsense 22.1.7_1-amd64 - FreeBSD 13.0-STABLE - OpenSSL 1.1.1o 3 May 2022). I notiche this during configuration using an old backup (virtual IP if modified take a /128 subnet), but I don't care enough at beginning.

Now It could be possible that something is not working as it should and I would like to have your opinion.

There's another strange behaviour that I'll test better tomorrow. Hard to explain, but as one of my nat problem is related to voip I tryed to do a packet capture. Well not only some packet are not recorded, but it seems that when packet capure is active, my nat problem disappear... OK probably I'm too tired  ;D

Anyway, I really appreciate your opinion.

Thanks