Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    PFsense 2.2.1 Inbound NAT Issues (RDP)

    Scheduled Pinned Locked Moved NAT
    14 Posts 3 Posters 4.3k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • D
      doktornotor Banned
      last edited by

      Which workaround? Post the FW rules screenshot and logs.

      1 Reply Last reply Reply Quote 0
      • H
        hartigan
        last edited by

        Workaround:
        Reply #4
        "Im seeing exactly the same issue as the o/p

        Open the nat rule, save, and its working again

        Only happened since going from 2.2 to 2.2.1"

        Forwarding rules and firewall rules attached.

        nat_rules.jpg
        nat_rules.jpg_thumb
        FW_Rules.jpg
        FW_Rules.jpg_thumb

        1 Reply Last reply Reply Quote 0
        • H
          hartigan
          last edited by

          Firewall logs from ext to one of the wan address Ext_to_Wan.jpeg
          Firewall logs from one of the wan address to ext Wan_to_Ext.jpg

          during RDP attempt from external

          Ext_to_Wan.jpg
          Ext_to_Wan.jpg_thumb
          ![Wan_to _Ext.jpg](/public/imported_attachments/1/Wan_to _Ext.jpg)
          ![Wan_to _Ext.jpg_thumb](/public/imported_attachments/1/Wan_to _Ext.jpg_thumb)

          1 Reply Last reply Reply Quote 0
          • D
            doktornotor Banned
            last edited by

            What are those aliases there? Does it work when you use the normal IP instead? I see absolutely nothing relevant on the firewall logs. Kindly filter the noise.

            @hartigan:

            Firewall logs from one of the wan address

            What do you mean? You have multiple WANs?

            1 Reply Last reply Reply Quote 0
            • H
              hartigan
              last edited by

              I've tried to build the FW rule using the direct lan ip rather the alias but it doesn't work anyway.

              If i build a block rule in the wan tab for the 23389 ( custom port ) and i try to connect to one of the wan ips on that port from external net, i can see it in the firewall log so i presume that the problem is between the wan and the lan interfaces.  >:(

              Thanks

              1 Reply Last reply Reply Quote 0
              • H
                hartigan
                last edited by

                @doktornotor:

                What are those aliases there? Does it work when you use the normal IP instead? I see absolutely nothing relevant on the firewall logs. Kindly filter the noise.

                @hartigan:

                Firewall logs from one of the wan address

                What do you mean? You have multiple WANs?

                Sorry, my bad.

                i've got only one wan with different virtual ips

                1 Reply Last reply Reply Quote 0
                • D
                  doktornotor Banned
                  last edited by

                  Post the output of

                  
                  pfctl -vvsa | grep rdr | grep 3389
                  
                  

                  (You'd hugely benefit from IPv6 instead of this port-forwarding mess.)

                  1 Reply Last reply Reply Quote 0
                  • S
                    Supermule Banned
                    last edited by

                    Dont you forward IPv6??

                    1 Reply Last reply Reply Quote 0
                    • H
                      hartigan
                      last edited by

                      @doktornotor:

                      Post the output of

                      
                      pfctl -vvsa | grep rdr | grep 3389
                      
                      

                      (You'd hugely benefit from IPv6 instead of this port-forwarding mess.)

                      $ pfctl -vvsa | grep rdr | grep 3389

                      @3(0) rdr on fxp0 inet proto tcp from any to 88.40.xxx.xxx port = 23389 -> <ts_qualita_108>port 3389 round-robin
                      @6(0) rdr on fxp0 inet proto tcp from any to 88.40.xxx.xxx port = 63389 -> <milano_ts>port 3389 round-robin
                      @7(0) rdr on fxp0 inet proto tcp from any to 88.40.xxx.xxx port = 53389 -> <panzieri_pc>port 3389 round-robin
                      @10(0) rdr on fxp0 inet proto tcp from any to 88.40.xxx.xxx port = 23389 -> <ts_ags_106>port 3389 round-robin
                      @11(0) rdr on fxp0 inet proto tcp from any to 88.40.xxx.xxx port = 23390 -> <ts_ags_114>port 3389 round-robin
                      @13(0) rdr on fxp0 inet proto tcp from any to 88.40.xxx.xxx port = 47246 -> <vm_ags_46_fn>port 3389 round-robin
                      @14(0) rdr on fxp0 inet proto tcp from any to 88.40.xxx.xxx port = 47245 -> <vm_ags_45_fn>port 3389 round-robin</vm_ags_45_fn></vm_ags_46_fn></ts_ags_114></ts_ags_106></panzieri_pc></milano_ts></ts_qualita_108>

                      1 Reply Last reply Reply Quote 0
                      • D
                        doktornotor Banned
                        last edited by

                        What's that round-robin nonsense there? Are you actually doing something useful with the "different virtual ips"? on WAN? If not, you'd just better remove them.

                        1 Reply Last reply Reply Quote 0
                        • H
                          hartigan
                          last edited by

                          Nothing except port forwarding. I should remove/disable the unused Virtual IPs?

                          This is the result of "diagnostics>packet capture" while i try to connect to one of the local machine from outside

                          10:24:23.819749 dc:7b:94:d9:fa:00 > 00:02:b3:d6:92:f0, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 111, id 6568, offset 0, flags [DF], proto TCP (6), length 52)
                              37.227.112.80.7616 > 88.40.xxx.xxx.23389: Flags , cksum 0x6eb6 (correct), seq 368944174, win 8192, options [mss 1380,nop,wscale 8,nop,nop,sackOK], length 0
                          10:24:28.232330 dc:7b:94:d9:fa:00 > 00:02:b3:d6:92:f0, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 111, id 6569, offset 0, flags [DF], proto TCP (6), length 52)
                              37.227.112.80.7616 > 88.40.xxx.xxx.23389: Flags , cksum 0x6eb6 (correct), seq 368944174, win 8192, options [mss 1380,nop,wscale 8,nop,nop,sackOK], length 0
                          10:24:32.761292 dc:7b:94:d9:fa:00 > 00:02:b3:d6:92:f0, ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 111, id 6570, offset 0, flags [DF], proto TCP (6), length 48)
                              37.227.112.80.7616 > 88.40.xxx.xxx.23389: Flags , cksum 0x82c5 (correct), seq 368944174, win 8192, options [mss 1380,nop,nop,sackOK], length 0
                          10:24:41.970859 dc:7b:94:d9:fa:00 > 00:02:b3:d6:92:f0, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 111, id 6571, offset 0, flags [DF], proto TCP (6), length 52)
                              37.227.112.80.7553 > 88.40.xxx.xxx.23389: Flags , cksum 0xdd69 (correct), seq 2149567383, win 8192, options [mss 1380,nop,wscale 8,nop,nop,sackOK], length 0
                          10:24:45.156284 dc:7b:94:d9:fa:00 > 00:02:b3:d6:92:f0, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 111, id 6572, offset 0, flags [DF], proto TCP (6), length 52)
                              37.227.112.80.7553 > 88.40.xxx.xxx.23389: Flags , cksum 0xdd69 (correct), seq 2149567383, win 8192, options [mss 1380,nop,wscale 8,nop,nop,sackOK], length 0
                          10:24:51.350903 dc:7b:94:d9:fa:00 > 00:02:b3:d6:92:f0, ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 111, id 6573, offset 0, flags [DF], proto TCP (6), length 48)
                              37.227.112.80.7553 > 88.40.xxx.xxx.23389: Flags , cksum 0xf178 (correct), seq 2149567383, win 8192, options [mss 1380,nop,nop,sackOK], length 0

                          1 Reply Last reply Reply Quote 0
                          • S
                            Supermule Banned
                            last edited by

                            Shouldnt be a problem using virtual IP's even unused ones.

                            Can you try to run the RDP client in 24 bit mode instead of 32 bit mode and see if this still occurs?

                            1 Reply Last reply Reply Quote 0
                            • H
                              hartigan
                              last edited by

                              Maybe i've "found" the solution. It's looks wired but it works.

                              I've made these steps:
                              1. System>Advanced>Firewall/NAT>Set "NAT Reflection Mode" from "disable" to "NAT + Proxy"
                              2. Save ( i've tried again with this option without success )
                              3. Step Back to "disable" and everything start working

                              I'm actually astonished  :o

                              I'm going to remove the unused Virtual IPs.

                              Thanks Everyone. I appreciate your help.

                              1 Reply Last reply Reply Quote 0
                              • First post
                                Last post
                              Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.