Yes, this looks like a firewall config issue, and likely also impacting on Avahi (as per opening post).

1 members found this post helpful.

The way your current firewall is configured, only traffic to and from 103.137.12.219/32 is allowed.

Please explain how your network is configured and where 192.168.0.14 fits into the scheme.

Activating and deactivating the firewall seems to make no difference at all, I still get the same output when I try to ping the printer. When I ping the printer using that ip address on a windows computer on the same wifi network it works fine. Strangely I can't even access my modem's admin page at 192.168.0.1 though again the windows computer has no problems. So my problem isn't just with the printer. But how can I be on the internet if I can't even log in to the router? Anything else I can try to narrow down where the problem might be?

In case it's any use:

rjh@rjh-NUC8i5BEH:~$ ifconfig
eno1: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether 1c:69:7a:0d:83:11 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 16 memory 0xc0b00000-c0b20000

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
loop txqueuelen 1000 (Local Loopback)
RX packets 1716 bytes 177572 (177.5 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1716 bytes 177572 (177.5 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
inet 10.8.0.8 netmask 255.255.255.0 destination 10.8.0.8
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 100 (UNSPEC)
RX packets 26496 bytes 18565737 (18.5 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 22007 bytes 2249842 (2.2 MB)
TX errors 0 dropped 27 overruns 0 carrier 0 collisions 0

wlp0s20f3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.12 netmask 255.255.255.0 broadcast 192.168.0.255
ether 38:00:25:8b:44:0d txqueuelen 1000 (Ethernet)
RX packets 40735 bytes 23738641 (23.7 MB)
RX errors 0 dropped 2 overruns 0 frame 0
TX packets 22393 bytes 4375616 (4.3 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

Are you using a VPN service?

1 members found this post helpful.

Oops, posted my last post without seeing the previous posts on page 2.
Yes, NordVPN. Tried disconnecting before starting this thread but that didn't seem to make any difference. Maybe if I uninstalled the software too.

After disconnecting, you could just flush the tables

1 members found this post helpful.

Okay, here's where I'm up to. Disconnected NordVPN, then ran . This killed my internet connection. I disabled NordVPN in autostart and rebooted. Internet is back. Ping now returns:

rjh@rjh-NUC8i5BEH:~$ ping 192.168.0.14
PING 192.168.0.14 (192.168.0.14) 56(84) bytes of data.
64 bytes from 192.168.0.14: icmp_seq=1 ttl=255 time=585 ms
64 bytes from 192.168.0.14: icmp_seq=2 ttl=255 time=454 ms
^C
--- 192.168.0.14 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 454.013/519.619/585.226/65.606 ms

Skanlite can now find the scanner and make scans. The printer still doesn't print though. A test page from the printer dialogue or pages from Libreoffice writer appear briefly in the print queue, spool, then disappear. No error messages at the pc end or on the printer, but nothing happens. Rebooted printer, checked that a windows pc can still print to it. Am scratching my head and trying to figure out what to do next. Try diferent connection in CUPS maybe?

As to where 192.168.0.14 is in my network setup I have no idea. Is there a command that would return this?

Thanks very much for all the help by the way.

Re where the printer is in the network setup this is my best effort so far.

And where the printer (192.168.0.14) sits in all this:

The printer's panel should be able to show its ip address or print a status/configuration page with the desired information.

1 members found this post helpful.

Hooray - it works! I assume it was NordVPN causing the problem. Now when I go into the CUPS interface and begin to modify the printer it recognises the printer sitting there, recommends a connection, (ipp://Brother%20MFC-J5330DW._ipp._tcp.local/) recommends a driver and sets the whole thing up.

This all makes sense now as I turn my VPN on and off a fair bit - on if I think I'm doing something dodgy, off if I want to watch streaming sport (which doesn't work if you have a VPN running).

For anyone trying to follow this the trick seems to be that the computer had to be restarted after disabling NordVPN for the printer to work again. Then it probably would have printed if not for a printer connection change I made along the way.

Assuming the printer stays fixed this time I just need to figure out how to run my VPN without it messing up the network, but that's probably better left for another thread if it comes to that.

To those who helped many thanks again. Anything else I should note for others before marking this as solved?

This could be due to an incorrect driver.

Post the output from

Thanks for the update. Good to know that the printer is working as expected. Check the route table after the VPN is disabled. Sometimes stale routes can cause issues.

The VPN when connected will route all traffic through the tunnel and not the LAN so accessing local devices does not work. Using split tunneling will allow both.

output of sudo egrep -i "filter|model" /etc/cups/ppd/*:

As far as I can tell this is the appropriate driver. It never really seemed like this would be a driver issue since it worked perfectly when it did work.

The route table is currently

but unfortunately I don't know if anything there is stale. (I've spent hours reading about networking over the last couple of days but I'm finding it a bit impenetrable. Even "basic" tutorials quickly lose me. Also I suspect some of the terminology is interchangeable so what they say to do in a how-to doesn't match what you see in your own settings. I suspect it takes a fair bit of concerted study to get on top of all this stuff.)

Re split tunneling I'll do some research but that sounds rather black-belt.

One last thing, I assume it would be appropriate to edit the title of this thread to better reflect that it relates primarily to VPN issues. And should it be moved to networking maybe?