Features of routing in CentOS or a story about crooked hands. What am I doing wrong?

Question

linux

Given

There are two networks: 192.168.3.0/24 and 192.168.10.0/24. Let's call them, for convenience, network A and network B.

In network A, the role of the gateway is performed by a machine on CentOS, which has two physical interfaces: eth0 (Internet, white IP) and eth1 (3.1, LAN). The default gateway, quite obviously, is eth0.

In network B, the gateway is DLink 250.

You need to connect these two networks using OpenVPN. At the moment, the server is DLink 250, 10.0 is indicated as a local network, and 3.0 as a remote network. The client is CentOS, the connection is established normally, a new tun0 interface appears (own IP 128.10.0.6, IP of the other end 128.10.0.5). Three new routes appear in the routing table:
- route to 128.10.0.5 via tun0,
- route to network 128.10.0.0 via 128.10.0.5 and tun0
- route to network 192.168.10.0 through 128.10.0.5 and tun0

Problem

From interface 128.10.0.6, network B pings fine. But, if you try to ping it from interface 3.1 or from network A in general, the packet dies somewhere after PREROUTING. It does not appear on any interface other than the incoming one, and is not caught in any rule other than PREROUTING. It seems that the kernel silently throws these packages into the trash.

CHADNT?

Answer 1

The reason has been found. The server admin tried to make an IPSEC tunnel through racoon first. Did not work out. Then he switched to OpenVPN. At the same time, despite the absence of an IPSEC tunnel and the killed SPD raccoon process, they remained quite alive and the kernel honestly tried to send the packet to where the sun does not shine. After setkey -FP, the packets flew to the right place, i.e. in tun0.
Many thanks to all who answered (and not only) for human participation.

Answer 2

Probably worth posting the results of the commands
ifconfig
ip r
iptables -nvL
iptables -t nat -nvL
Openvpn configs and logs.
And they will help you faster.
Well, if you are too lazy, then just try to listen to what is happening there, for example like this:
ngrep -W byline -d tun0 host xxx.xxx.xxx.xx and port xxxx
PS And you did not forget to do this
echo "1" > /proc/sys/net/ipv4/ip_forward
Or more globally in the /etc/sysctl file .conf in line
net.ipv4.ip_forward = 1

Answer 3

Can add to the routing table a route to 192.168.3.0 through 128.10.0.5 and tun0?

Answer 4

Show then the iptables rules

Answer 5

you should choose a class C network for openvpn because

whois 128.10.0.5
#
# Query terms are ambiguous.  The query is assumed to be:
#     "n 128.10.0.5"
#
# Use "?" to get help.
#

#
# The following results may also be obtained via:
# http://whois.arin.net/rest/nets;q=128.10.0.5?showDetails=true&showARIN=false&e                                                                                             xt=netref2
#

NetRange:       128.10.0.0 - 128.10.255.255
CIDR:           128.10.0.0/16
OriginAS:
NetName:        PURDUE-CS-EN
NetHandle:      NET-128-10-0-0-1
Parent:         NET-128-0-0-0-0
NetType:        Direct Assignment
RegDate:        1984-08-01
Updated:        2009-06-19
Ref:            http://whois.arin.net/rest/net/NET-128-10-0-0-1

OrgName:        Purdue University
OrgId:          PURDUE
Address:        Information Technology
Address:        155 S. Grant Street
City:           West Lafayette
StateProv:      IN
PostalCode:     47907-2114
Country:        US
RegDate:
Updated:        2010-09-20
Ref:            http://whois.arin.net/rest/org/PURDUE

OrgNOCHandle: PNOC-ARIN
OrgNOCName:   Purdue Network Operations Center
OrgNOCPhone:  [phone]
OrgNOCEmail:  [email protected]
OrgNOCRef:    http://whois.arin.net/rest/poc/PNOC-ARIN

OrgAbuseHandle: PUISP-ARIN
OrgAbuseName:   Purdue University STEAM-CIRT
OrgAbusePhone:  [phone]
OrgAbuseEmail:  [email protected]
OrgAbuseRef:    http://whois.arin.net/rest/poc/PUISP-ARIN

OrgTechHandle: PURDU-ARIN
OrgTechName:   Purdue Hostmaster
OrgTechPhone:  [phone]
OrgTechEmail:  [email protected]
OrgTechRef:    http://whois.arin.net/rest/poc/PURDU-ARIN

RTechHandle: DT50-ARIN
RTechName:   Trinkle, Daniel
RTechPhone:  [phone]
RTechEmail:  [email protected]
RTechRef:    http://whois.arin.net/rest/poc/DT50-ARIN

#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#

Answer 6

The specs for D-link do not state that he can openvpn.

Answer 7

plz output: ip ro on 3.1
route to network B are you transmitting using openvpn?
openvpn server and client configs will not hurt

Answer 8

ip ro output in the comments above
the route (three routes, to be precise) is transmitted by means of openvpn
I can’t show the server config (there is only a web interface), the client config:
client
nobind
remote ZZ.ZZ.ZZ.ZZ 1194
proto udp
resolv-retry infinite
dev tun
log /etc/openvpn/openvpn.log
persist-key
persist-tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/1.crt
key /etc/openvpn/1.key
cipher AES-128- CBC
auth SHA1
verb 7
route-delay 6

Answer 9

I don't see the prerequisites for this, but try

echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter

Answer 10

then do the opposite.
centos server and dlink client and look

Answer 11

then take another computer that you make a client and test there