Outbound rule not working?



  • Bear with me, i slapped my head for too much time on this.

    For some time the rule worked and nothing changed so i dont know whats wrong...

    I have a 3CX PBX and i followed the instructions on how to setup properly pfsense to make 3cx work.

    The instructions are here: https://www.3cx.com/docs/pfsense-firewall/ and they are very easy: a list of port to port forward and a rule for Outbound nat for a static port but seems that the static port is not working because the port match is wrong:
    3cxfail.jpg
    In 3cx there is a tool that allow to test the port forward and as you can see is a mess. Pfsense is giving me random ports like the rule is not even there.
    What i tried:

    1. Obviously reboot: the 3cx server, pfsense and even the modem. Fail
    2. Remove and recreate the rules. Fail
    3. Reset states on every thing that i modified. Fail

    The ports are random just after a reboot. Than i get the same port every time i test (like 5090 and 61068)

    Any suggestion?

    Screenshot of the rule
    3cxfail2.jpg



  • @exico said in Outbound rule not working?:

    Any suggestion?

    That guide is for an older version of pfSense. It doesn't even show Hybrid rules.

    Post your outbound NAT rules. Looks like your rule somehow got changed from static to dynamic port translation.



  • Yeah, its very old.
    I forgot to tell that i tried both manual and hybrid.
    Anyway now its in hybrid as i have another similar configuration in another location and works.

    By the way my 3cx server have 192.168.7.2 as ip

    3cxfail3.jpg

    EDIT: i tried also to change the server IP (and any rule related to it) . Got the same result..


  • LAYER 8 Netgate

    I would verify that those connections are actually being made from 192.168.7.2 and that connections are not actually going out 4GTIM instead. That static port rule looks correct.

    Packet captures are your friend when debugging voip.



  • Ok, i did some digging using the packet capture in pfsense. Bear with me, i never used it.

    First i did some testing with only one interface enabled (VDSLTIM) and disabled 4GTIM just to be sure that there is just one way out and surprise. Did not change anything.

    I used the packet capture while starting the test in 3CX and i do not understand it fully:
    From VDSLTIM Interface:

    15:31:50.086973 IP (tos 0x0, ttl 128, id 17106, offset 0, flags [none], proto UDP (17), length 56)
        192.168.11.2.5090 > 151.80.125.93.3478: [udp sum ok] UDP, length 28
    15:31:50.115801 IP (tos 0x0, ttl 50, id 16544, offset 0, flags [DF], proto UDP (17), length 116)
        151.80.125.93.3478 > 192.168.11.2.5090: [udp sum ok] UDP, length 88
    

    From VLAN INTERFACE:

    15:33:45.450024 IP (tos 0x0, ttl 128, id 17827, offset 0, flags [none], proto UDP (17), length 56)
        192.168.7.2.5090 > 151.80.125.93.3478: [udp sum ok] UDP, length 28
    15:33:45.478829 IP (tos 0x0, ttl 49, id 30856, offset 0, flags [DF], proto UDP (17), length 116)
        151.80.125.93.3478 > 192.168.7.2.5090: [udp sum ok] UDP, length 88
    

    Lets take this part as example, the corrisponding part in 3cx test is this one:
    2019_05_11_15_32_32_3CX_Phone_System_Management_Console.jpg

    For context:
    The network for this part is as follows: 192.168.7.x (voip vlan and 192.168.7.2 is the voip server) -> 192.168.7.1 (pfsense gateway for the vlan) -> 192.168.11.2 (pfsense client) -> 192.168.11.1 (ISP router) -> Internet
    Its a double NAT (yeah its ugly, im looking into transforming it in a bridge) and on the ISP router pfsense is set in DMZ
    I believe that 151.80.125.93 is the 3CX test server

    From what i understand the port is mapped correctly but the tool reports that the mapping its wrong. Correct?
    I also cant find the port 64201 on the log captured

    EDIT: 3CX is not at version 15.5 and its available the v16. I will try to upgrade and see if its just a bug in the tool


  • LAYER 8 Global Moderator

    @exico said in Outbound rule not working?:

    Its a double NAT

    Well does that nat in front of pfsense also do static ports? if its some soho router I doubt it.


  • LAYER 8 Netgate

    Your VDSLTIM address looks to be RFC1918 (192.168.11.2) so something upstream must also be performing NAT. It will ALSO need to do the correct thing with the ports.

    You can plainly see that pfSense is not translating the port there as instructed.

    Connection comes from 3CX sourced from 192.168.7.2.5090
    Connection is address translated out VDSLTIM but the source port is static: 192.168.11.2.5090


  • LAYER 8 Global Moderator

    Think you meant to say pfsense "is" doing it correctly since the source is 5090.

    His error is saying its 64201 which clearly points to another nat happening upstream of pfsense.


  • LAYER 8 Netgate

    Right - not translating the port as instructed

    Yeah that's worded funny. "It is not translating the port. The port is static. pfSense is doing what it has been instructed to do."



  • Im not so knowledgeable in networking so maybe i worded it bad.
    The traffic from internet goes this way:

    Internet(public IP) ->router(192.168.11.1)->DMZ to 192.168.11.2(pfsense)->192.168.7.1(pfsense)->192.168.7.2(3CX)

    If i setup a DMZ between pfsense and the stupid ISP router isnt it sufficient? It would redirect everything as it is to the DMZ

    In my previous post seems that the port is translating correctly (5090) but in 3CX Firewall check i get a "mapping error" reporting that another port is mapped but i cannot find anything related to this port in the packet logs.

    It bothers me because i have the same setup in another location with router, DMZ, pfsense and 3CX and everything works with no problems and the check tool doesnt report wrong mappings.

    I will try to set the router in bridge mode (if its even possible) in the first occasion and report back


  • LAYER 8 Netgate

    Your upstream device is performing the source port translation. There is nothing pfSense can do to stop that.



  • OK. The stupid modem/router wasnt translating correctly. In bridge it works flawlessy.
    The only difference from this and my other location is the router. Here i have a tg789vac from Technicolor and branded TIM (the ISP); the other one is a Dlink DVA-5592, is not branded and the ISP is Wind. (Italian ISPs).
    Guess that the dlink with only DMZ set up does also the static port and the Technicolor not. Good to know.

    Thank you for your help. Much appreciated.


Log in to reply