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.
    • H
      hartigan
      last edited by

      Hi,
      after 2.2.1 upgrade i've encountered some problem with inbound NAT

      I've got some forwarding rules (working on PFsense 2.2) set like that:
      External request>Wan address:customport>lanaddress:RDPport

      Now, every RDP inbound rule is not working. This workaround doesn't worked for me https://forum.pfsense.org/index.php?topic=90930.0

      Any suggestions?

      1 Reply Last reply Reply Quote 0
      • 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.