Unable to reach modem

Hi, since today, after reboot, I have problems with internet, sometimes it works sometimes not. I then set out to find the problem and I realized that if I try to reach the modem, I am redirected to the router, it has never happened to me and I do not know how to solve the problem, I think it was a packet update, also because I have not touched the network settings since I configured the system, provided that it was not an update of the modem by my ISP.

My simple line is structured as follows
Modem -> 192.168.1.1
Router (R7800) -> 10.0.0.1 with OpenWrt 18.06.4, r7808-ef686b7292
On the modem everything is deactivated and a DMZ is active towards the MACADDRESS of the Router.
So the router takes the ip address 192.168.1.150
The router manages the network with DHCP and uses CloudFlare DNS.

What do you think I can do?
What configurations can I post to try to understand where the problem is?

J

1 Like

A little update, my wan6 is teorically disabled

But I see this on Routes


Is that normal?
Sorry but I'm not expert in networking, I've very basic knowledge on this

Collect the diagnostics and post it to pastebin.com redacting the private parts:

ubus call system board; uci show network; uci show firewall; \
ip address show; ip route show table all; ip rule show; iptables-save -c
1 Like

Hi, here the pastebin logs

Let me know if you need more/extra information

1 Like

The cause of the problem appears to be the interface eth1.1.
It should have no IP address configured by itself as a bridge slave for the br-lan.
This looks like a runtime setting as there're no persistent configs related to the current state.
You can remove the conflicting IP address like this:

ip address delete 192.168.1.1/24 dev eth1.1

Or, try to reboot the router and check if the issue persists.

3 Likes

If I'm right that IP address is coming from the test wireguard table (TEST_WG_PIA), maybe through policy based routing?

Yes, PRB is installed.
On router I've
VPNSERVER -> 10.8.0.1
PIA_WG that wireguard client

Wireguard is only for one device (10.0.0.100), all traffic for this device pass through wireguard, for this I use PBR, but I need some extra rule to reach 10.0.0.100 when I use VPN connection from outside, so my PBR configuration is

config policy
	option name 'Ignore Local Requests by Destination'
	option dest_addr '10.8.0.0/24'
	option interface 'ignore'

config policy
	option interface 'wan'
	option name 'Ftp-Rule1'
	option src_addr '10.0.0.100'
	option src_port '20-21'

config policy
	option interface 'wan'
	option src_addr '10.0.0.100'
	option name 'Ftp-Rule2'
	option src_port '6900-7000'

config policy
	option chain 'PREROUTING'
	option name 'Nas'
	option proto 'tcp udp'
	option src_addr '10.0.0.100'
	option interface 'TEST_WG_PIA'

config vpn-policy-routing 'config'
	option verbosity '2'
	option ipv6_enabled '0'
	option strict_enforcement '1'
	option boot_timeout '30'
	list ignored_interface 'vpn_server'
	option src_ipset '0'
	option iptables_rule_option 'append'
	option iprule_enabled '0'
	option webui_enable_column '0'
	option webui_protocol_column '0'
	option webui_chain_column '0'
	option webui_sorting '1'
	option webui_show_ignore_target '1'
	list webui_supported_protocol 'tcp'
	list webui_supported_protocol 'udp'
	list webui_supported_protocol 'tcp udp'
	list webui_supported_protocol 'icmp'
	list webui_supported_protocol 'all'
	list supported_interface 'pia_vpn'
	list supported_interface 'test_wg_pia'
	option enabled '1'
	option dest_ipset '0'
	option resolver_ipset 'dnsmasq.ipset'

config include
	option path '/etc/vpn-policy-routing.netflix.user'
	option enabled '0'

config include
	option path '/etc/vpn-policy-routing.aws.user'
	option enabled '0'

Do you think is here the problem?
I can try with your command vgaetera, if all works after that ok, but what if not works? How can I redo this command?

J

Executed and now if I go to 192.168.1.1 I land to modem page, so is right! Thanks.
I'll have to test all others functions but for now it works.

Do you think I'll have the same problem after a reboot? If yes is possible to avoid it?

J

1 Like

According to your configs, this shouldn't happen.
If the issue persists, additional diagnostics is required:

grep -r -e 192[.]168[.]1[.]1 /etc

Ok, thanks, I'll reboot the router to see if that happen again, in case, I'll provide more log

J

I confirm that the problem persist after a reboot, the grep return this

root@OpenWrt:~# grep -r -e 192[.]168[.]1[.]1 /etc
/etc/config/openvpn_recipes:    option server_bridge    '192.168.1.1 255.255.255.0 192.168.1.128 192.168.1.254'
/etc/ethers:#   02:00:11:22:33:44       192.168.1.1

Is normal that is bridged?

1 Like

That's weird, the grep result appears to be unrelated to the cause.
You can try disabling extra services to identify the faulty one.

Extra services like PBR, adblock etc etc?
What do you think is best to do?
Disable all then reboot, then enable one service then reboot and so on?
Or maybe is like firewall related, and I can skip some?

J