JoshuaPK wrote
Hello All!
I have a weird routing issue. My network configuration is the following:
- A subnet with a number of servers (192.168.4.0/24)
- On that subnet, a CentOS 7 server acting as OpenVPN server. It has an address on the 192.168.4.0/24 network, and it hands out addresses on the 192.168.15.0/24 network. Its address on that network is 192.168.15.1
- A CentOS 8 server that is at a remote location. It connects to the OpenVPN server and gets an IP address of 192.168.15.2.
I have everything locked down pretty tight. The SSH server on 192.168.15.2 will only permit connections from a management server that exists at 192.168.4.90. However... when I connect from that server, the SSH logs on 192.16.15.2 show a connection from 192.168.15.1, NOT 192.168.4.90. I have triple checked that all of the firewalld settings on both the OpenVPN server and the remote server are not configured for Masquerade. How can I ensure that 192.168.4.0/24 traffic is not being NAT'd into the 192.168.15.1 address?
Thanks!
-JK
I am replacing existing, working routers with ER-12's. So, the ISP is not the problem.
I have multiple class-c routable blocks. The ISP passes all 3 blocks to our existing (old) 'head-end' router. One of those blocks is the block used by the existing router for it's LAN side. The other two are passed down to two other existing routers. The 'down-stream' routers each have use a routeable class-c without NAT. One of those is a test network. I replaced the test network's router with an ER-12.
The instructions, in the link, do not say that any firewall rules are needed. Just the ETH9 WAN interface and the LAN interface (I used switch0.) With it set up such, it did not route. For a test, I simply added a NAT statement, and it routed, but of course the addresses passed upstream were wrong. (As provided by a "what is my IP' web site.)
Since my initial post, I have gotten it to route by adding FIREWALL statements with established/related/new enabled/
upsers.
I don't know if that is the 'right' way, but at least it routes. between the WAN and LAN segments. If there is a better way, I am open to what that way should be.
You asked about the test that failed. The 'test' is simply being able to ping the WAN address of the ER-12 from a PC connected on the LAN side of the same ER-12. It fails without either a NAT set up or a FIREWALL set up.For me, one or the other must be used.
