DyDNS and Port FWD with OpenVPN client



  • I'm trying to get AIrVPN ip addresses updated with Namecheap dynamic dns but unfortunately this is not happening and port forward is not working. If however I uncheck :

    Don't pull routes
    Don't add/remove routes

    from the VPN client settings, then the IP address starts updating and port forward also works, but it also forces all the attached devices to the network to use the VPN connection, which I don't want.

    Is there a way around this?



  • I've got the port forwarding to work on my VPN by disabling this rule (the rule was originally checked). However, DynDNS is still not working.

    System/Advanced/Firewall & NAT

    0_1546000316237_Screenshot 2018-12-28 at 12.27.16.png



  • For port forwarding, you shouldn't have needed to disable that rule, you need two things... 1) make sure the firewall rules on your OpenVPN interface are explicit, so traffic is not matched on the wrong interface. 2) verify the port forwards are on the AirVPN interface and the destination is the AirVPN_WAN address

    For DynDNS, are you updating via PFsense or a software client on a PC? If you're updating thru PFsense, then you have to make sure you're monitoring the AirVPN interface that was created during your setup. If you're using a software client to update, then you have to make sure the IP that the PC is using is routed down the AirVPN tunnel and NAT'd accordingly.

    I use AirVPN also and have both of these things working.



  • @marvosa

    You have DynDNS updating on you AirVPN WAN interface?

    In you AIrVPN client setup do you have the following options checked or unchecked?

    Don't pull routes
    Don't add/remove routes



  • You have DynDNS updating on you AirVPN WAN interface?

    Yes, we have dynamic dns working on the AirVPN WAN interface. Although, we're using dynu.com and not dyndns specifically, but yes, it's working on the AirVPN WAN interface using a custom URL.

    In you AIrVPN client setup do you have the following options checked or unchecked?

    Don't pull routes

    Don't add/remove routes

    Both options are checked:

    0_1546011798941_68c3aa1a-9541-4f14-8560-db57ea1c5332-image.png



  • Nothing worked for me, I think it's because i have to 2 separate networks, 1 going through AirVPN and the other is going through my normal WAN. The best solution I found was to setup a separate pfsense firewall dedicated for AirVPN, which is working great for me at the moment. The firewalls are virtualised so not a big problem.



  • @slim2016 said in DyDNS and Port FWD with OpenVPN client:

    Nothing worked for me, I think it's because i have to 2 separate networks, 1 going through AirVPN and the other is going through my normal WAN. The best solution I found was to setup a separate pfsense firewall dedicated for AirVPN, which is working great for me at the moment. The firewalls are virtualised so not a big problem.

    It doesn't matter how many networks you have as long as all the pieces are in the right place and configured on the correct interface.

    Are you trying to update Namecheap via the PFsense Dynamic DNS service or via a software client on a PC?

    I would verify several things:

    • Verify the port is forwarded on the front end (AirVPN). Once the port forward has been verified at the VPN provider, one of the first things people do is verify traffic is actually making it to the firewall and second is to verify that the return traffic is exiting the correct interface. This is done via packet capture (Diagnostics -> Packet capture).

    • Verify traffic sourced from the IP's/Networks you want using AirVPN are routed down the tunnel via policy-based routing.

    • Verify there is an outbound NAT for traffic sourced from all IP's (or subnets) you want routed out the AirVPN interface

    • Verify your port forwards are configured on the correct interface and have the correct destination (AirVPN interface and destination address)

    • Verify traffic is not being matched on the wrong interface. In other words, the rules on your OpenVPN tab should be explicit and not the default any/any. In other words, any rules on the OpenVPN tab should have an explicit source and destination or traffic will get sent out the wrong interface and will break port forwarding



  • @marvosa

    I've already got my port forwarding to work, it's my DynDNS which is not updating the AirVPN IP address on pfsense.

    "There was an error trying to determine the public IP for interface - opt1 (ovpnc2 )"

    That's the error i'm getting.



  • Here's our working config for dynu:

    Service Type = Custom
    Interface to monitor = AIRVPN_WAN (whichever interface is assigned to the AirVPN tunnel)
    Interface to send update from = AIRVPN_WAN (whichever interface is assigned to the AirVPN tunnel)
    Verbose logging = unchecked
    HTTP API DNS Options = unchecked
    HTTP API SSL Options = unchecked
    Username = leave blank
    Password = leave both fields blank
    Update URL = custom url provided by dynu.com
    Result Match = good|nochg|good %IP%
    Description = whatever you want

    Since DynDNS is in PFsense's list of service types, there are fewer options and it's only looking for creds and a hostname. A few things to look at:

    • The only other thing I can think of is maybe there's a NAT missing for when the traffic is sourced by the firewall itself. Verify there's a NAT mapping for traffic sourced from 127.0.0.0/8 on the AIRVPN interface.
    • Last but not least, you could also try checking the DynDNS website for instructions for updating via custom URL instead of hostname and creds to see if it works that way.

    If all of the above check out, then the only thing to do is enable verbose logging on the DDNS service to see if something reveals itself in the logs and/or start running packet captures for analysis.



  • I'm using Namecheap, which is listed in pfsense dydns drop down list, i've also tried the custom url from Namecheap, which also failed to update.

    I already have 127.0.0.0/8 in the NAT Outbound settings for AirVPN WAN interface.

    The credentials are correct since it updates when using the WAN interface.