Connection appears to be in wrong direction

curl

My pfSense box, a Dell PC, has 4 interfaces labeled WAN,LAN,LAN2,IOT with WAN connected to ISP router. I sometimes observe states on LAN2 that do not seem to be labeled in the correct direction. For example in,

where each smudged IP address represents the same internet IP address, the LAN2 state seems to be labeled in the wrong direction for a connection that should have originated on LAN2. I only observe this on LAN2, and only for some clients on LAN2.

I use schedules and pass/block rule pairs to limit the access of some clients to the internet on a schedule. When one of these 'backwards' connections is made for a client with a schedule, it is not passed by the rule with a schedule so it is not killed when that pass rule becomes inactive.

Can someone please point out what I am missing?

curl

@curl I determined that the 'backward' connection is allowed by rule 59 which is,
@59(0) pass out quick on re2 proto tcp all flags any keep state (sloppy) ridentifier 1000000552

The LAN2 interface is re2. How can I determine which setting generated this rule? I have looked at each rule on LAN2, hovering over the blue text in States column to view the Tracking ID and none match the ridentifier above.

Gertjan

@curl said in Connection appears to be in wrong direction:

1000000552

You can't find 1000000552 in /tmp/rules.debug ?

curl

@gertjan said in Connection appears to be in wrong direction:

You can't find 1000000552 in /tmp/rules.debug ?

In /tmp/rules.debug i find,

pass in quick on { re2 } proto tcp from any to { 192.168.10.1 } port { 8003 8002 } ridentifier 1000000551 keep state(sloppy)
pass out quick on { re2 } proto tcp from any to any flags any ridentifier 1000000552 keep state(sloppy)

The 2nd line corresponds to rule 59 and the line above is referencing captive portal network ports. I have captive portal on LAN2. The sequential ridentifiers makes me think rule 59 may be related to captive portal.

Gertjan

@curl said in Connection appears to be in wrong direction:

makes me think rule 59 may be related to captive portal.

Humm.

I'm using myself a captive portal also on a "LAN2" (ex. OPT) interface.
Try this : disable the portal, and see again /tmp/rules.debug, how it changes.

I'm used to see ipfw rules myself for the last decade or so. The latest pfSense is using an "all fp" solution for the captive portal, ipfw isn't needed anymore.

I'm not a state or pf expert, but there is one thing I know : If there are no NAT rules, then no traffic initiated from Internet (the WAN interface) can reach your LAN interfaces.

curl

Thanks for the suggestion, @Gertjan. Noting that rule 59 refers to 'sloppy' states, I searched for other sloppy states in console shell,
[root@pfSense /var/log]# pfctl -vvsr | grep "sloppy"
@57(0) pass in quick on re2 inet proto tcp from any to 192.168.10.1 port = 8003 flags S/SA keep state (sloppy) ridentifier 1000000551
@58(0) pass in quick on re2 inet proto tcp from any to 192.168.10.1 port = 8002 flags S/SA keep state (sloppy) ridentifier 1000000551
@59(0) pass out quick on re2 proto tcp all flags any keep state (sloppy) ridentifier 1000000552

After disabling captive portal, there are no longer any sloppy state rules and no rules with ridentifier 1000000552.

Gertjan

@curl

Same thing for me :

# Captive Portal

pass in quick on igc1 proto tcp from any to <cpzoneid_2_cpips> port 8003 ridentifier 13001 keep state(sloppy)
pass out quick on igc1 proto tcp from 192.168.2.1 port 8003 to any flags any ridentifier 13002 keep state(sloppy)
pass in quick on igc1 proto tcp from any to <cpzoneid_2_cpips> port 8002 ridentifier 13003 keep state(sloppy)
pass out quick on igc1 proto tcp from 192.168.2.1 port 8002 to any flags any ridentifier 13004 keep state(sloppy)
pass in quick from any to any tagged cpzoneid_2_passthru ridentifier 13005 keep state
block in quick on igc1 from any to ! <cpzoneid_2_cpips> ! tagged cpzoneid_2_auth ridentifier 13006

"igc1" is my captive portal interface.

curl

@curl Resolved ( I think ).
I used tcpdump and wireshark to show conversations while a schedule was active,

$ wireshark -k -i <(ssh root@192.168.10.1 tcpdump -i re2 -U -w - )

and used pfsense Diagnostics/States to view states after the schedule had timed out.

A conversation on LAN2 ( 192.168.10.0/24 ) during active schedule,

and Diagnostics/States after schedule had timed out,

My explation is as follows ( please correct my if I am wrong ). The conversation in wireshark view was created by the pass rule with a schedule. When that schedule timed-out, pfSense killed one direction of the connection, the state originating on LAN2. The state inbound on WAN was not killed. Rule 59 ( above ) allowed packets from that external IP address to pass in to LAN2 and pfSense created a new state ( 2nd state in diagnostics view ).

My hack:
At System/Advanced/Firewall & NAT I have set, 'State Timeouts / TCP Established' shorter than the period for which the schedule is inactive. That should force pfSense to kill both states of a connection before the schedule is activated again.