I have a situation with a Debian Jessie server where I am manually creating an IP route, and after the first time I use it, it stops working.

On my network, I have 192.168.2.0/24 and 192.168.1.0/24 subnets which are mostly isolated. However, in my Cisco RV325 router, I allow an exception for 192.168.2.* traffic to 192.168.1.* hosts (but not vice versa). This works fine for all other clients (MacOS, Win10) on my 192.168.2.* subnet, without additional configuration.

However, on my 192.168.2.* Debian server, I cannot reach 192.168.1.* hosts. So, I tried manually adding a route (on the Debian box) via

root@debian$ route -v 

Kernel IP routing table 

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface 

default         router          0.0.0.0         UG    1024   0        0 eth1

192.168.2.0     *               255.255.255.0   U     0      0        0 eth1



root@debian$ route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.2.1 metric 1



root@debian$ route -v

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

default         router          0.0.0.0         UG    1024   0        0 eth1

192.168.1.0     router          255.255.255.0   UG    1      0        0 eth1

192.168.2.0     *               255.255.255.0   U     0      0        0 eth1

At this point, I can successfully connect to a HTTP host on the other virtual LAN:

root@debian$ telnet 192.168.1.24 80

Trying 192.168.1.24...

Connected to 192.168.1.24.

Escape character is '^]'.

I can manually ask for a webpage, for example, and the content gets returned. The connection is then closed, and any subsequent attempt fails:

Trying 192.168.1.24...

telnet: Unable to connect to remote host: No route to host

The route -v still shows the route I added, but it's essentially unusable. What is going wrong here? Is some other piece of software likely actively shutting down what it thinks are illegitimate routes?

I have seen this related question, and tried all three current answers, none of which worked for me.

I tried disabling Network Manager altogether, but that broke my default route, which is a much more serious problem. So, I am posing this question as "how to add a route to another subnet on a system with Network Manager"? Manually, or automatically on boot, are both fine.

Update

Per questions below, iptables shows:

root@debian$ iptables -vnL

Chain INPUT (policy ACCEPT 5376 packets, 1052K bytes)

 pkts bytes target     prot opt in     out     source               destination         

 2490  184K fail2ban-ssh  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            multiport dports 22



Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)

 pkts bytes target     prot opt in     out     source               destination         



Chain OUTPUT (policy ACCEPT 3041 packets, 1187K bytes)

 pkts bytes target     prot opt in     out     source               destination         



Chain fail2ban-ssh (1 references)

 pkts bytes target     prot opt in     out     source               destination         

   13  1016 REJECT     all  --  *      *       154.8.139.43         0.0.0.0/0            reject-with icmp-port-unreachable

    0     0 REJECT     all  --  *      *       192.99.122.172       0.0.0.0/0            reject-with icmp-port-unreachable

 2477  183K RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0       

None of those IPs seem relevant. Before posing the question, I did try disabling the fail2ban service, with no effect.

ip addr on the debian host shows:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

    inet 127.0.0.1/8 scope host lo

       valid_lft forever preferred_lft forever

2: eth2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000

    link/ether 00:26:55:db:36:fa brd ff:ff:ff:ff:ff:ff

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000

    link/ether 00:26:55:db:36:fb brd ff:ff:ff:ff:ff:ff

    inet 192.168.2.34/24 brd 192.168.2.255 scope global eth1

       valid_lft forever preferred_lft forever

Note: I do have a second NIC (eth2) on the machine, but it's unplugged and DOWN. Not present in routing table.

This is almost likely not a routing issue on your client - rather it is likely to be a firewall issue or issue on the server.

My guess would be incorrect routing on the server due to an incorrect netmask there (Maybe 255.255.0.0 which is fairly common), combined with reverse path filtering on the client. You can check this by, for example, disabling reverse path filtering on the client with a command like echo "1" > /proc/sys/net/ipv4/conf/default/rp_filter - but the solution is to fix the networking on the server because the packets are not being sent back to the router. (This may also involve allowing "RELATED" traffic back in the router).

If that fails, Look at the iptables rules to see if it is being blocked there - you can see these by typing iptables -vnL. (You may want to post these for us to have a look at). It could also be related to the router, conceivably even a NAT related issue.

Generally, where possible, the next step is to do some packet sniffing to see what is leaving the computer and what is being received by the web server and vv. You can use tcpdump (in a seperate window and then make a request) with a command like

tcpdump -n -i eth1 tcp src or dst 192.168.1.24

(I note that the route command you have added is redundant - and I suspect you misunderstand its purpose. This is not the cause of your issue though. If the problem relates to Reverse path filtering, you might be able to bypass the router alltogether with a command like route add -net 192.168.1.0 netmask 255.255.255.0 eth1)