Bug #13389
closedIPsec filter rules do not match Mobile IPsec traffic when Captive Portal is enabled.
0%
Description
Running 22.05 amd64
The following rule exists at the top of the IPsec interface:
pass in quick on enc0 inet from 172.25.100.1 to any flags S/SA keep state label "USER_RULE: test" label "id:1659457945" ridentifier 1659457945
When Captive Portal is disabled, the Android client traffic is passed by the rule. When Captive Portal is enabled, the traffic is dropped.
Aug 2 11:53:22 gw filterlog[73268]: 4,,,1000000103,enc0,match,block,in,4,0x0,,64,1850,0,DF,1,icmp,84,172.25.100.1,10.0.5.1,request,68,164
Captive Portal config is basic:
<captiveportal> <guest> <zone>guest</zone> <descr><![CDATA[LAN]]></descr> <localauth_priv></localauth_priv> <zoneid>2</zoneid> <interface>lan</interface> <maxproc></maxproc> <timeout></timeout> <idletimeout></idletimeout> <trafficquota></trafficquota> <freelogins_count></freelogins_count> <freelogins_resettimeout></freelogins_resettimeout> <enable></enable> <auth_method>none</auth_method> <auth_server></auth_server> <auth_server2></auth_server2> <radacct_server>localhost</radacct_server> <reauthenticateacct></reauthenticateacct> <httpslogin></httpslogin> <httpsname>gw.home.arpa</httpsname> <preauthurl></preauthurl> <blockedmacsurl></blockedmacsurl> <certref>5b26b60fbf62b</certref> <redirurl></redirurl> <radmac_format>default</radmac_format> <radiusnasid></radiusnasid> <termsconditions></termsconditions> <page></page> </guest> </captiveportal>
IPsec is a Mobile client configuration using EAP-MSChapv2.
Updated by Jim Pingle about 3 years ago
- Status changed from New to Not a Bug
- Priority changed from High to Normal
Unless I'm missing something here that's normal and expected.
Traffic to a host on LAN from anywhere, including IPsec, would be dropped by the portal rules unless the source and/or target is passed through captive portal or the target host is logged into captive portal.
Now that it's all handled in pf that means it hits a visible block rule instead of disappearing into ipfw
never to be seen again.
Updated by Marcos M about 3 years ago
I should have clarified.
LAN2 is 10.0.5.1 (where I'm trying to get to from the client)
LAN is 10.0.1.1 (where CP is)
CP should not be coming into play here at all.
Updated by Marcos M about 3 years ago
- Status changed from Not a Bug to Duplicate
This issue exists on a build before the Jun 22nd release. This has already been fixed - NG #8287.