Source address not NATed during OpenVPN startup?

[stephenw10]

Mmm, if if was NATing to the LAN IP or using the OBN rules at all you would see it in the created states.

Since it's being passed by a state opened on LAN you could try adding a block rule on LAN to prevent it as a workaround.

Steve

[bPsdTZpW]

@stephenw10 said in Source address not NATed during OpenVPN startup?:

Mmm, if if was NATing to the LAN IP or using the OBN rules at all you would see it in the created states.

Since it's being passed by a state opened on LAN you could try adding a block rule on LAN to prevent it as a workaround.

Steve

What block rule could I use? From the point of view of the LAN interface, the packets are perfectly OK (src:LAN device, dest:internet).

[stephenw10]

It's source: LANaddress destination: Internet though and it's outbound which should never happen.

You want to make it as specific as possible so I'd use a floating, quick, outbound rule, source: LANaddress destination: some-test-address. Make sure that does something useful and does block expected traffic before changing the destination to some thing wider.

Steve

[bPsdTZpW]

@stephenw10 said in Source address not NATed during OpenVPN startup?:

It's source: LANaddress destination: Internet though and it's outbound which should never happen.

You want to make it as specific as possible so I'd use a floating, quick, outbound rule, source: LANaddress destination: some-test-address. Make sure that does something useful and does block expected traffic before changing the destination to some thing wider.

Steve

I think I see. I already have a rule like this, and it doesn't work. From the original post:

I have put various "reject" floating rules on outbound WAN [by which I meant floating, WAN, outbound] to prevent these packets from exiting [1]...[1] e.g. action:block, quick, interface:WAN_IGB0, direction:out, family:IPV4+IPV6, protocol:any, source:RFC1918, destination:any, extra options:log, no advanced options.

I also tried putting such a rule on the LAN interface (out, reject, quick, src RFC1918, dest <test IP>) and, as expected, it did nothing.

[stephenw10]

Hmm, check the actual state as it appears in the state table. Try using pfctl -vvss

If it creates a state it should be possible to add a rule that prevents it.

Steve

[bPsdTZpW]

@stephenw10 said in Source address not NATed during OpenVPN startup?:

Hmm, check the actual state as it appears in the state table. Try using pfctl -vvss

If it creates a state it should be possible to add a rule that prevents it.

Steve

So after the bad packets have passed, pfctl -vvss gives many states of this form:

all tcp <website IP>:443 <- <LAN IP>:64970       CLOSED:SYN_SENT
   [0 + 16777216]  [1164774331 + 33554432]
   age 00:01:20, expires in 00:00:40, 1:1 pkts, 52:80 bytes, rule 122
   id: 4c80166200000000 creatorid: c79f1419 gateway: 0.0.0.0
   origif: igb1

which presumably correspond to some of the bad packets.

However, there are also a few state pairs that appear to correspond to working, NATed packets. The first state of the pair is very similar to the bad state, above, so I don't see how I could filter on it:

all tcp <website IP>:443 <- <LAN IP>:64972       TIME_WAIT:TIME_WAIT
   [4088558557 + 132096] wscale 7  [1887699560 + 1282998272] wscale 8
   age 00:01:20, expires in 00:01:13, 268:128 pkts, 27167:143271 bytes, rule 122
   id: 4d80166200000000 creatorid: c79f1419 gateway: 0.0.0.0
   origif: igb1

all tcp <WAN IP>:32245 (<LAN IP>:64972) -> <website IP>:443       ESTABLISHED:ESTABLISHED
   [3162374760 + 8323072] wscale 8  [4088558557 + 132096] wscale 7
   age 00:01:20, expires in 23:59:24, 268:128 pkts, 27167:143271 bytes, rule 74
   id: 4e80166200000000 creatorid: c79f1419 gateway: <WAN gateway>
   origif: igb0

This really seems like a bug.

[stephenw10]

It does. The only way I could possibly see anything sourced from the LAN IP itself would be some sort of proxy running. So Squid, HAProxy or NAT reflection in NAT+Proxy mode.

What is rule 122 in your ruleset?

Steve

[bPsdTZpW]

@stephenw10 said in Source address not NATed during OpenVPN startup?:

It does.

The only way I could possibly see anything sourced from the LAN IP itself would be some sort of proxy running. So Squid, HAProxy or NAT reflection in NAT+Proxy mode.

Nope, nope, and nope. The setup is quite vanilla. I have one package: service_watchdog.

What is rule 122 in your ruleset?

The only rule having any such number in the output of pfctl -vvsa is

@122(0) block drop in log quick on igb0 inet6 proto udp from any to any port = nameserver label "USER_RULE: Ports to monitor" ridentifier 1628204890
  [ Evaluations: 0         Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: pid 61558 State Creations: 0     ]

which makes not the least bit of sense. This is an inbound WAN block/log rule I use to see how many attempts at common ports the bad guys are making. Am I reading the numbers wrong?

[stephenw10]

Mmm, indeed. Can you see what rule 122 is or was when the OpenVPN is up?

This starts to look like a stale state somehow.

[bPsdTZpW]

@stephenw10 said in Source address not NATed during OpenVPN startup?:

Mmm, indeed. Can you see what rule 122 is or was when the OpenVPN is up?

That rule is from after OpenVPN came up. I don't know what the numbering was before it came up; it would be tricky to get; I'd probably need to write a script.

This starts to look like a stale state somehow.

Well, I did find that setting Reset All States in System/Advanced/Networking reduces (but does not zero) the number of bad packets.