I'm trying to setup DDNS to update freedns.afraid.org. However, I have a Tunnel configured to route all of my traffic through an external VPN provider.
When the DDNS client (inadyn?) runs, a request is sent to freedns.afraid.org, but the dns record is updated to the public ip address of the vpn service I use rather than my wan ip.
Add WAN IP to Inadyn?
The FreeDNS.afraid.org documentation states its possible to override automatic IP detection:
Quote:
You can override automatic IP detection host by appending &address=127.0.0.10 to any update URL
Is it possible to configure DDNS to add an additional querystring in the update http call? IE
Policy Based Routing for Router Traffic
I also tried to exclude traffic originating from my router from being routed through my VPN tunnel by using configuring the PBR of my Tunnel as:
Source routing (PBR): Route selected sources via WAN
Source for PBR: 192.168.99.5,192.168.99.1
(My router address is 192.168.99.1. 192.168.99.5 is a different device on my LAN that is not routed through my VPN).
This setup didn't seem to impact my DDNS traffic - freedns.afraid.org was still getting set to my VPN public ip address. I also tried the following command to see my external ip, and it is also showing my public VPN ip address rather than my route address.
Code:
wget -qO- http://ipecho.net/plain | xargs echo
Is it possible to use PBR to exclude traffic generated on my router from being routed through the VPN Tunnel?[/quote]
The above would go in the Additional Config field.
P.S. The above is only necessary when NOT using PBR (policy based routing). IOW, when you're routing ALL your WLAN/LAN traffic through the VPN. But once you enable PBR for *any* reason, it removes the router itself from the VPN, and therefore ALL of the router's internet access defaults to the WAN.
INADYN doesn't support https. If DDNS is not updating, you should use http://server.fqdn.here:443/whatever.else.here. _________________ "The woods are lovely, dark and deep,
But I have promises to keep,
And miles to go before I sleep,
And miles to go before I sleep." - Robert Frost
"I am one of the noticeable ones - notice me" - Dale Frances McKenzie Bozzio
I tried eibgrad's suggesting to use route. I didn't see the route directive, but I did see Destination Routing:
Code:
Destination routing: Route selected destinations via WAN
Destination for PBR: freedns.afraid.org
This ended up working, FreeDNS see's the update request coming from my WAN IP, rather than my public VPN IP, and so is updated correctly.
Interestingly enough, other machines on my network though can no longer access freedns.afraid.org. None of them need to, but I found this a very odd side effect.
Per eibgrad's comment - I AM using PBR, but from my observations it doesn't appears that the router itself was removed from VPN. It's traffic still appears to be routed. As I mentioned in my initial post, if I go to ADMINSITRATION -> COMMNANDS and run:
Code:
wget -qO- http://ipecho.net/plain | xargs echo
This returns the IP of my public VPN, not my WAN IP.
Per egc comment about DDNS using WAN IP address - I think this is correct in so far as the router is using the WAN IP address to determine if it's necessary to make a change. However, when the router does make the change, by making an http request to freedns.afraid.org, freedns see's the request coming via the public VPN I use, and it updates to that IP.
Per dale_gribble39 comment about INADYN not supporting https, I don't think I need https here (though it would of course be preferred for security reasons). My issue was my ddns update request to freedns.afraid.org was getting routed through my public VPN, so when afraid.org used the IP of the request, it would get the public VPN IP rather than my WAN ip.
Glad you got it sorted. But keep that tidbit for future info just in case freedns.afraid.org stops accepting your updates. _________________ "The woods are lovely, dark and deep,
But I have promises to keep,
And miles to go before I sleep,
And miles to go before I sleep." - Robert Frost
"I am one of the noticeable ones - notice me" - Dale Frances McKenzie Bozzio
The point in using PBR is to prevent the router from changing the default gateway to the VPN, so *all* internet access defaults to the WAN, including the router itself. In order to route specific LAN devices through the VPN, you need to use PBR (specifically source routing in this case). And there's no way to make the router participate in the VPN using source routing since its LAN network interface (e.g., 192.168.1.1) is NOT used for internet access, but rather the WAN.
Given all that, I can't see how the router magically ended up in PBR.
The alternative is to NOT use PBR, but just create a static route (as I described previously) in the Additional Config field of the OpenVPN client. It's really that simple.
Perhaps you did more here than was necessary or expected. Hard to say since we can't see exactly what you did. You've only reported the results.
P.S. The following comment makes me even more suspicious about what you did.
