Hi
I managed to get a connection to my brothers Fritzbox. I see the interface comming up and get an ip address assigned.
But the connection also sets the defaultroute to the vpn connection ... so I can access all systems in my brother's netwok, but I lost my route to the internet.
Also, when I disconnect the interface, the default route is not set back.
I found a patch in the current sources (I've installed 18.06.2) and after looking at it I added
option defaultroute '0'
to the interface in /etc/config/network
Now the default route stays on the wan interface, but I don't have a route to the 192.168.10/24 net on my brother's location. The vpnc interface does not show up in the route table.
I added 192.168.10.1/255.255.255.0 in the target network field in the confirguration but that does have no affect.
I added a static route via luci but that did also have no affect.
Other than that post the vpnc configuration as well as the following (while connected): cat /etc/config/network; cat /etc/config/firewall; ip -4 addr ; ip -4 ro ; ip -4 ru; nslookup www.openwrt.org
Is your brother's fritzbox also advertising back to your router the 192.168.10.0/24 or the 0/0?
Anything in the logs?
Other than that try to be as compatible as possible with the template config.
On my brothers side the endpoint is a single IP as shown in the first picture with ip in the local network (192.168.10.202). It is doint nat on my side.
This works ok ... the problem seems to be the not set correct routes on my side as well as that on going down the connection the routes are not cleand up.
Googling brings up that this is a common problem and suggest is a manual cleanup of the routes (way too complicated I think).
This is the IP assigned to you from the server. The problem is that it is a /32 so you cannot use it for something. Normally the server side must advertise to the client the available networks. Check if that applies.
Which command do you use to setup the routes?
Routes bound to an interface that goes down will automatically be deleted, so the clean up is not an issue.
I see some options missing. If you don't use them they will use default option, which might not be ideal.
Did you ever end up getting it to work?
I am using 19.07 on WDR4300 trying to establish a connection to a FB 6490.
I think the Fritzbox does not publish a target network so there is no route to the target network, just like ne20002 describes.
If I set the VPN connection to be the default gateway, IP addresses on the other end become pingable from the OpenWRT shell but not from clients, despite adding the vpn interface to the LAN zone.
There is very little information about the interconnectivity between OpenWRT and Fritzbox routers. I had followed this guide but like I said I run into the same problem as ne20002: https://www.sebastianklein.de/blog/vpn-zwischen-lede-openwrt-und-fritzbox-via-luci/
I am not sure how related my issues was to this problem, but since it also involves a FritzBox chances are my fix would help someone.
First I reverted to using the VPN as a Default Gateway (in the settings of the interface). This was not an issue for me because this router has no other purpose than that.
Once I did that, I was able to ping a device on the other side from OpenWRT's shell but not from a client connected to the OpenWRT router (Wifi or LAN).
The solution was adding a new zone for the VPN:
Network-Firewall: Add…
Name ‘tun0zone’
Input: reject
check Masquerading
check MSS clamping
Covered networks: check ‘tun0’
Click ‘Save and Apply’
Followed by adding that zone in the firewall Zone settings (/admin/network/firewall) to the lan => wan entry at zone => forwarding:
In zones ‘lan => wan’ click edit
At the bottom of the general settings in "Allow forward to destination zones", leave ‘wan’ checked, and also check ‘tun0zone’
Click ‘Save and Apply’
Yes and no. I go the encryption and the tunnel to work. But as the endpoint has been a FritzBox in germany with always changing IP address ... that didn't work and required a manual restart of the interface each day.
So I migrated all external VPN connections to wireguard and solved this issue with placing a Raspberry Pi in the remote network.