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

    NAT Reflection status?

    Scheduled Pinned Locked Moved NAT
    2 Posts 1 Posters 1.1k 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.
    • S
      sporkme
      last edited by

      I think I pretty much understand how the reflection options are supposed to work, but I'm having issues (2.1.4) and I'm wondering if there are any caveats that I don't know of.

      Currently, I'm able to get reflection working only with the proxy option.  I do not want to use this option for two reasons:

      •It appears all external traffic passes through the proxy
      •All traffic appears to come from the proxy, so any services that log a source address no longer have the "real" source, everything appears to come form pfsense itself

      Two things that I have configured that I'm not sure are compatible with the standard reflection rules are using virtual IPs for the NAT rules (additional external addresses - "if alias" type) and a legacy bridge interface I'm trying really hard to get rid of (chicken and egg problem - need to get NAT working before I can yank the bridge interface).

      When I initiate a connection from inside to a service that's forwarded on the outside with "pure nat" reflection enabled, I see no packets blocked in the firewall logs.  For state entries, I see the following:

      Proto	Source -> Router -> Destination	State	
      tcp	192.168.11.102:22 <- x.x.x.222:22 <- x.x.x.211:55418	CLOSED:SYN_SENT
      tcp	x.x.x.211:51893 -> 192.168.11.102:22	SYN_SENT:CLOSED
      

      x.x.x.222 is an alias on pfsense's wan interface
      x.x.x.211 is the wan interface's main IP
      192.168.11.102 is the port forward target IP

      Not seen there is the connection source, which is 192.168.11.101.

      If I'm reading this right, there's no state being generated from 192.168.11.101 to the ultimate destination after NAT of 192.168.11.101, and the state entries shown above represent the destination (192.168.11.102) reaching back to pfsense's main WAN IP and the second state entry is likely the already-translated source IP hitting the destination.

      What's going wrong in this scenario?

      Is my bridge interfering in some way?

      Is reflection not supported with if aliases?

      What else can I do to troubleshoot?

      1 Reply Last reply Reply Quote 0
      • S
        sporkme
        last edited by

        Hmmm…  Maybe I'm on to something here.

        If I run tcpdump on the bridge interface while attempting the connection, I see this:

        16:33:25.603399 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.x.x.222 tell 0.0.0.0, length 50
        16:33:26.714153 IP (tos 0x0, ttl 64, id 12716, offset 0, flags [DF], proto TCP (6), length 60)
            x.x.x.211.59721 > x.x.x.222.22: Flags [s], cksum 0x210a (correct), seq 2823335170, win 65535, options [mss 1460,nop,wscale 3,sackOK,TS val 753592721 ecr 0], length 0
        16:33:29.914115 IP (tos 0x0, ttl 64, id 12731, offset 0, flags [DF], proto TCP (6), length 60)
            x.x.x.211.59721 > x.x.x.222.22: Flags [s], cksum 0x148a (correct), seq 2823335170, win 65535, options [mss 1460,nop,wscale 3,sackOK,TS val 753595921 ecr 0], length 0
        
        So it looks like my reflections are reflecting, but rather than the packets hitting the virtual IP, they are heading out the bridge.[/s][/s]
        
        1 Reply Last reply Reply Quote 0
        • First post
          Last post
        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.