suddendly I get a "bad source address from client" on OpenVPN, yet everything is working



  • today out of the blue my OpenVPN server started to complain about this:

    vpnuser/REMOTE_IP:PORT MULTI: bad source address from client [192.168.1.2], packet dropped 
    

    the config, both on the client and the server, is unchanged, everything was working well before today, no such message.
    the weird thing is that everything is working as expected, I can reach all other clients on that VPN and the pfsense box/OpenVPN server itself as well. I can also reach other VPN networks that are behind the same pfsense box (different OpenVPN servers) with no issue.
    Still, if I reconnect to this VPN from my home I get that message in the logs.
    192.168.1.2 is the private IP that my home router supplies me, the REMOTE_IP:PORT is the IP address of the carrier NAT from my provider (I don't have a proper public IP at home, carrier grade NAT, everything was working tho, it's not blocking VPN at all)

    the only weird thing I noticed in the logs is that tonight the main Gateway had an alert because there was some packet loss, but it went back to the default gateway on it's own, and I don't think this should have affected the OpenVPN network.

    I'm connecting from a home connection and I think, but I'm not sure, the ISP changed my IP, but that as well shouldn't have caused that problem, I'm authenticating with SSL/TLS + User Auth on a Remote access OpenVPN server, dynamic IP in client settings is checked with Topology subnet.

    what could be causing that error message, especially considering everything works? should I make a client specific override and add as remote network 192.168.1.0/24?

    I want this OpenVPN server to route all client traffic through it, so that shouldn't be necessary, and it is routing all my client traffic through it.

    on my client:
    $ route
    Destination Gateway Genmask Flags Metric Ref Use Iface
    default 10.0.2.1 0.0.0.0 UG 50 0 0 tun0
    default _gateway 0.0.0.0 UG 600 0 0 wlp3s0
    10.0.2.0 0.0.0.0 255.255.255.0 U 50 0 0 tun0
    VPN_SRV_PUBLIC_IP _gateway 255.255.255.255 UGH 600 0 0 wlp3s0
    192.168.1.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp3s0
    _gateway 0.0.0.0 255.255.255.255 UH 600 0 0 wlp3s0
    192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0



  • I did add a client specific override for my user certificate adding 192.168.1.2 in the remote network address, now I get this in the logs

    vpnuser/REMOTE:IP:PORT MULTI: Learn: 192.168.1.2 -> vpnuser/REMOTE_IP:PORT
    

    what I don't understand is why I didn't needed it before, I also checked if I could reach my home laptop from other hosts on the VPN (or behind another VPN client on a different OpenVPN server on the same box) and I could, even without the client specific override.

    I must not understand fully what's what in OpenVPN, because if OpenVPN couldn't route internally 192.168.1.2 before why were the packets still reaching me?



  • From info given you don't really need the iroute.
    This can also happen when on LTE/4G/mobile network.

    Also better to avoid common subnets, read here:
    https://community.openvpn.net/openvpn/wiki/AvoidRoutingConflicts



  • @Pippin said in suddendly I get a "bad source address from client" on OpenVPN, yet everything is working:

    From info given you don't really need the iroute.

    exactly, and it's plain wrong as well, in fact it wasn't set up with the unnecessary iroute and I had no such message in the logs, afaik nothing major changed on my side of things.
    I am connecting from a home connection which is actually a 4G router, no adsl reaches where I live, and the carrier did change something because their NAT address definitely changed before this happened, but I can't fathom how that would cause that message on my logs.

    luckily this is just a VPN connection I use to admin the firewall from my laptop from remote locations and from home if needed, so nothing critical, the critical VPNs this box handles are untouched by this issue and the logs are clean.

    I should have avoided common subnets from the beginning, guess it's time to do that now and see if that has any impact, it's good practice anyways.


Log in to reply