which interface to listen on

Thank you @sindy.

It might be the case that not all frames are captured on the virtual interface. Let me describe the issue in grater detail, maybe you can point me in the right direction on how to troubleshoot further. We have a client software that needs to download a policy from server. It fails while connected via VPN. I've tried to perform a Wireshark capture but I cannot see any SYN packets coming from the client's IP address at all. I was capturing on the affected laptop but what's strange that I can see his IP as the destination and not as the source in the packets. Do you have any ideas?

Thank you Adam

Unfortunately, there is no way to affect how a proprietary code, like the one of the Cisco virtual interface, handles packet capturing. So if I've understood you right, you have already captured at server side and haven't seen there any incoming SYN packets from the client. As you cannot usefully capture at the virtual interface on the laptop, you have to use different approach to the analysis.

The first thing I would ask myself at your place would be "is the routing correct"? AFAIK the Cisco VPN supports two modes, one where the default route at the client PC is changed to the VPN tunnel, and another one where the default route remains as it was and only a list of IPs and subnets which should be routed to the tunnel is sent to the client.

So when the VPN connection is active, check your routing table and see whether the route to the server is the tunnel or to the LAN's router.

Or, as we are on a Wireshark site, capture at the client's LAN interface and start the application. If you can see SYN packets towards the server's IP address there, it means that they are misrouted.

If any of the two methods shows routing misconfiguration, fix it in client's settings at the VPN access gateway.

Another possibility could theoretically be that the client application somehow binds to the address of the LAN interface and uses that address as source for the packets it sends regardless the actual source interface, and the virtual interface filters out any packets bearing different source address than its own one.

@sindy I highly appreciate your feedback. Thank you. I was testing it with another VPN solution and it worked BUT the VPN solution i was testing with didn't install a virtual NIC unlike CISCO AnyConnect. Can it be somehow linked with what you wrote " Another possibility could theoretically be that the client application somehow binds to the address of the LAN interface and uses that address as source for the packets it sends regardless the actual source interface, and the virtual interface filters out any packets bearing different source address than its own one." ? If yes, how would I troubleshoot that ?

I wonder how a VPN solution could work without a virtual interface it would offer to the network stack. It is more likely that it creates one dynamically, but that doesn't help you solve your issue.

You haven't said how the routes looked like when the Cisco VPN connection was active; did you check that?

To confirm that the application chooses one IP address and uses it as source for all requests regardless from which interface they are actually sent, you would need to use another network card (an USB one should be easiest to deploy) and another router to which it would be connected; the "WAN" interface of the router would be connected to the same network like the other network card of the laptop.

                          internet
                             |
                [gateway router of subnet A]
                             |
Subnet A --------------------------------------------
             |                              |
             |                [gateway router of subnet B]
             |                              |
             |       Subnet B -----------------------------
             |                              |
      on-board NIC ... of the laptop ... USB NIC

Then you would set the default route of the PC first to the "LAN" IP addres of the gateway router of subnet A (or just check that it is set like that), start capturing at both network interfaces of the PC, and start the application. You should see the SYN packet on one of the interfaces. Next, you would change the default route of the PC to the "LAN" IP address of the gateway router of subnet B and do the same.

Now:

• if in both cases the source IP of the SYN packet is the same (matching one of the two interfaces' IP addresses), the hypothesis is confirmed;

• if in both cases the source IP of the SYN packet matches the IP of the interface from which it is physically sent, the hypothesis is denied.

@Sindy. I'm going to troubleshoot it further tomorrow but there's something i don't understand in relation to the routing hints. I mean, I can still ping / telnet to the server while connected via VPN. Wouldn't that mean that the routing is fine (I know that I didn't mention that ping and telnet work though). Or is your concern related to the issue that the application chooses one IP and uses it as source for all requests regardles from which interface they are actually sent ?