Default route not recognized when IP address on WAN is static

Hi, can anyone help me, I am new with OpenWrt and can not understand why is this happening.

So, when WAN interface is configured with DHCP assignment:

network.wan=interface
network.wan.ifname='eth1'
network.wan.proto='dhcp'

I have default gateway running and everything is ok:

root@OpenWrt:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         10.0.10.1       0.0.0.0         UG    0      0        0 eth1
10.0.10.0       *               255.255.255.0   U     0      0        0 eth1
172.16.0.0      *               255.255.255.0   U     0      0        0 wg0
192.168.1.0     *               255.255.255.0   U     0      0        0 br-lan

But, when I assigned static IP address and default gateway on WAN interface I do not have default route recognized:

network.wan=interface
network.wan.ifname='eth1'
network.wan.proto='static'
network.wan.ipaddr='10.0.10.100'
network.wan.netmask='255.255.255.0'
network.wan.gateway='10.0.10.1'
network.wan.dns='8.8.8.8'
root@OpenWrt:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         *               0.0.0.0         U     0      0        0 wg0
10.0.10.0       *               255.255.255.0   U     0      0        0 eth1
172.16.0.0      *               255.255.255.0   U     0      0        0 wg0
192.168.1.0     *               255.255.255.0   U     0      0        0 br-lan

Wireguard is taking precedence.

But, why is he not taking precedence when WAN interface get it's IP address by DHCP?

What is the difference?

I need static IP address on WAN interface because of WireGuard VPN. How can I solve this situation?

Quick solution is to configure a static lease for the OpenWrt, so that it takes the same reserved IP from DHCP server.

To answer the other questions you need to show us the configuration file:
uci export network
Most likely the wg0 is coming up after the wan when set to static and replaces the default route. It could be solved as easily as changing interface metrics.

root@OpenWrt:~# uci export network
package network

config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fda9:5c31:6423::/48'

config interface 'lan'
        option type 'bridge'
        option ifname 'eth0.1'
        option proto 'static'
        option ipaddr '192.168.1.1'
        option netmask '255.255.255.0'
        option ip6assign '60'

config interface 'wan'
        option ifname 'eth1'
        option proto 'static'
        option ipaddr '10.0.10.100'
        option netmask '255.255.255.0'
        option gateway '10.0.10.1'
        option dns '8.8.8.8'

config interface 'wan6'
        option ifname 'eth1'
        option proto 'dhcpv6'

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option ports '1 2 3 4 0t'

config interface 'wg0'
        option proto 'wireguard'
        option private_key '*hash*'
        option listen_port '1234'
        list addresses '172.16.0.1/24'

config wireguard_wg0
        option public_key '*hash*'
        option preshared_key '*hash*'
        option route_allowed_ips '1'
        list allowed_ips '0.0.0.0/0'
        option persistent_keepalive '25'
        option description 'user'

These are your mistakes.
The peer user is supposed to provide internet to the OpenWrt router or just to connect as RoadWarrior?
And fix the post above to include the console output in preformatted text, the </> button.

1 Like

User is connecting as Remote Access VPN user.

I made changes to the interfaces adding the metric:

config interface 'wan'
	option ifname 'eth1'
	option proto 'static'
	option ipaddr '10.0.10.100'
	option netmask '255.255.255.0'
	option gateway '10.0.10.1'
	option dns '8.8.8.8'
	option metric '10'
config interface 'wg0'
	option proto 'wireguard'
	option private_key '+D/hwn8MwV+GTxuAnkGWx4XH2wEEey1pCjIVeev2j2w='
	option listen_port '1234'
	list addresses '172.16.0.1/24'
	option metric '100'

And now the routing table looks like this:

root@OpenWrt:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         10.0.10.1       0.0.0.0         UG    10     0        0 eth1
default         *               0.0.0.0         U     100    0        0 wg0
10.0.10.0       *               255.255.255.0   U     10     0        0 eth1
172.16.0.0      *               255.255.255.0   U     100    0        0 wg0
192.168.1.0     *               255.255.255.0   U     0      0        0 br-lan

Default route is working, but will be the problem having 2 default routes?

No, this is wrong!
Remove the route_allowed_ips from user peer and change the allowed_ips to the IP the user is configured to get, e.g 172.16.0.2/32

1 Like

I did what you suggested me to do, and routing table was good: (I removed metric from interfaces)

root@OpenWrt:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         10.0.10.1       0.0.0.0         UG    0      0        0 eth1
10.0.10.0       *               255.255.255.0   U     0      0        0 eth1
172.16.0.0      *               255.255.255.0   U     0      0        0 wg0
192.168.1.0     *               255.255.255.0   U     0      0        0 br-lan

I did not understand these two settings:

  1. allowed_ips="0.0.0.0/0" : IP addresses and prefixes that this peer is allowed to use inside the tunnel, also used for Wireguard's internal routing table. (I meant this is like some kind of ACL, so which destinations RA VPN client can access to)
  2. route_allowed_ips="1" : Automatically create a route for each Allowed IPs for this peer. (And I meant this is the route toward this allowed IP addresses)

Certainly, I was wrong, and thanks for clarifying this.

You can interpret it as an ACL, however is the source and not the destination.

This has sense if the peer has some more networks behind it, for example a 192.168.100.0/24. Then you'd have to define it in the list of allowed IPs and also route it in order to install a static route for it via the WG tunnel.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.