strange openVPN traffic: interface mismatch

gridrun

Hi all,

I'm unsure of the following firewall log entry caught on an OpenVPN server box:

Mar 20 21:01:31 - Action=Block, Interface=WLAN, Source=172.26.1.97:1027, Destination=172.27.0.1:36669, Proto=TCP, Flags=S

A priori knowledge:
a) The block action is a result of an anti source spoofing rule on the WLAN interface, discarding all traffic originating from outside the assigned 172.27.0.0/16 network.
b) The WLAN Interface has 172.27.0.1/255.255.0.0 assigned to it (Ethernet connecting to Switch/APs).
c) The OpenVPN has 172.26.0.1/255.255.0.0 assigned to it (VPN Subnet).
d) 172.26.1.97 is a valid openVPN Client (Win32), ifconfig pushed from the server by client specific configuration.
e) This VPN uses /30 subnets.

Analysis of the log entry:
The packet appears to be a TCP SYN request directed to the OpenVPN server IP:port (172.27.0.1:36669), presumably coming from the OpenVPN client trying to establish a connection with the server.

Anomalies detected:
1) The source address of the packet belongs to the VPN network (172.26.x.x)
2) However, the interface on which this packet came in is actually the WLAN interface (172.27.x.x)

At first, it looks like openVPN client is "simply" leaking packets to the WLAN that should actually go through the VPN. Then again, this makes no sense because if the VPN client tries to connect and is still at the SYN stage, then obviously the VPN connection can't be up and running yet. It's rather strange to see the client's VPN subnet IP appear as the source address of a packet on the WLAN. Even stranger when considering that the VPN client->server connection was only just being set up (TCP SYN sent to server socket) at that time.

A bug, perhaps? If so, it's not mission critical. Subsequent TCP SYNs are sent via the correct interface, the connection establishes and everything works as it should (except for throughput, but that's another story). Still, I would like to understand what happens. Can someone provide more insight?

Cheers
Chris

janjust

can the openvpn client send packets directly to the wlan interface of the server? is the client in the same office as the server?

gridrun

Hey,

Yes, the WLAN infrastructure is local to our building. All network cabling is GigE, except for the AP uplinks which are 100mbps each connected to a GigE switch (these cables also carry PoE to the APs). The setup is illustrated below, but for simplicity I put just one AP when there are really 7 of em:

Physical: [Win32 Laptop]<---WLAN 802.11n Lite--->[AP]<---100--->[Switch]<-GigE->[pfSense]<-------->[CISCO WAN]
Logical:  [oVPN Client]<----------------------------------------------------->[oVPN Server]<------>[INTERNET]

The APs are bridged to the Ethernet backbone, as to allow WLAN users to roam freely across the entire building. AP isolation is enabled to isolate a particular AP's clients from each other. The GigE Switch implements layer 2 isolation between the APs. DNS and DHCP for the WLAN is done by the pfSense box on the WLAN interface. The WLAN is open (no encryption). Internet access is not possible from the WLAN directly and all HTTP traffic (dst port 80 TCP) over the WLAN is redirected by DNAT on the pfSense to an informational web page.

The openVPN client (installed on Win32 Laptop here) connects via this WLAN to the openVPN Server on the pfSense box. Once connected to the VPN, users have Internet access from there.

So the openVPN actually protects all client traffic over the WLAN and gives us a fixed "virtual endpoint" (the VPN IP Address, so to speak) for each connected client. These endpoint addresses are completely decoupled from the WLAN addressing. This enables secure bandwidth management and access control for each VPN endpoint while still using DHCP on the WLAN. Network management is much easier this way. Security is improved over "regular" WLAN because the openVPN (with TLS), together with the complete layer 2 isolation of clients and APs makes it rather difficult to hijack another user's IP or launch certain attacks.

janjust

ah now I understand...
actually, I'm used to seeing the reverse: non-VPN packets which are sent over the VPN link. This has nothing to do with OpenVPN but with the way Windows sends (smb? dcom? ) traffic around. If the packet arrives on the WLAN interface then openvpn had nothing to do with it - the windows kernel decides which i/f to send a packet out from, not OpenVPN.
I think you can safely ignore these packets.

gridrun

Jan,

Thanks for the heads up. Since all of these packets come from one and the same client, I now suspect the bug's actually not even in the windows kernel but probably in some firewall/antivirus product installed on that particular client.

In any way, no problem.

Thanks
Chris