Devices in sub-network in ORANGE cannot see other devices in orange

mastergeekmx · 30 November 2022 00:17

Hailings and thanks for the time.

I am working in a university computing lab and I set up a spare PC with IPFire as the new firewall device for the whole lab.

Here is a diagram of the network as is with the names of the hosts on it changed for security reasons:

The firewall has several IP aliases that map to the hosts in ORANGE, for example: 10.50.1.100 is the public address of yucon, and locally yucon is 192.168.1.100 to allow external acces to them

Also atlantis has a firewall and a bridge setup to allow all the atlantisN nodes to have internet access.

The only rules I have setted up in IPFire are allowing SSH (port 22) and HTTP (port 80) from ANY source to be NAT port forwarded onto the corresponding host in ORANGE.

But starting a few weeks ago, all the atlantisN hosts cannot see any host in ORANGE. No ping, no ports open according to nmap, no server to respond to web requests of any kind, anything. as far as they are concerned, they do not exist.

funny thing is that atlantisN hosts have perfectly fine internet access.

Also, both atlantis and all the hosts in GREEN can establish a connection perfectly to the hosts in ORANGE and use all the services on those hosts, even the ones that aren’t SSH and HTTP.

cfusco · 30 November 2022 09:47

Few questions:

is atlantis able to see youcon and the other orange machines?
is atlantis doing a DHCP to atlantisN machines?
is atlantis doing a NAT (which would be a double NAT with IPFire being the first) on port 22 and 80?
is atalntis1 able to ping atlantis?
is atlantis1 able to ping atlantis2?

tphz · 30 November 2022 14:56

Could you please complete the graphic with IP addresses and masks?
Could you show the result of the command ip route on atlantis, atlantis1, yucon

mastergeekmx · 30 November 2022 21:18

is atlantis able to see youcon and the other orange machines?
Yes. all of them. no problems between devices in the orange network.
is atlantis doing a DHCP to atlantisN machines?
no. it is another machine in the atlatis network using dnsmasq.
is atlantis doing a NAT (which would be a double NAT with IPFire being the first) on port 22 and 80?
I think so. I haven’t seen exactly how, but it is managed by firewalld. if the service is down, no atlantisN host has internet access.
is atalntis1 able to ping atlantis?
is atalntis1 able to ping atlantis2?
Yep. all atlantis machines can see each other with no issues.
Could you please complete the graphic with IP addresses and masks?
Indeed. all networks (even RED) use 255.255.255.0 as netmask:

Could you show the result of the command ip route on atlantis, atlantis1, yucon

atlantis:

default via 192.168.1.251 dev enp4s0 
169.254.0.0/16 dev enp3s0 scope link metric 1002 
169.254.0.0/16 dev enp4s0 scope link metric 1003 
192.168.1.0/24 dev enp4s0 proto kernel scope link src 192.168.1.254 
192.168.2.0/24 dev enp3s0 proto kernel scope link src 192.168.2.254

atlantis1:

default via 192.168.2.254 dev eth1 proto static metric 100 
192.168.2.0/24 dev eth1 proto kernel scope link src 192.168.2.1 metric 100

yucon:

default via 192.168.1.251 dev eth0 proto static metric 100 
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.228 metric 100

tphz · 30 November 2022 21:49

Could you show the result of the command ip route on IPFire

Edit

It might be a routing problem.
Yukon and other hosts on the Orange network need an additional gateway to connect to hosts on the “atlantis” network.
Please, see the similar topic below

cfusco · 1 December 2022 15:52

Because there is not a specific route for 192.168.2.0/24 in Atlantis (and the other orange machines) and everything goes to IPFire, I think all the packets sent to Atlantis from AtlantisN are forwarded to IPfire and therefore they get dropped by IPFire kenel if they are not addressed directly to the red interface of IPFire, probably due to the change in Reverse Path Filter setting.

This would explain the sudden loss of connectivity. Did you update IPFire from core 168 around the time the problem did arise? There is a simple way to test this hypothesis, deactivate the strict path filtering (*) in IPFire and if this is correct you should be able to ping again the machines in orange:

(*) type this with root privileges in IPFire console, 1 to go back to strict RPF

sysctl net.ipv4.conf.default.rp_filter=2
sysctl net.ipv4.conf.all.rp_filter=2

mastergeekmx · 1 December 2022 20:24

Here it is:

[root@firewall ~]# ip route
default via 148.206.49.251 dev red0 
148.206.49.0/24 dev red0 proto kernel scope link src 148.206.49.229 
148.206.49.251 dev red0 scope link 
192.168.0.0/24 dev green0 proto kernel scope link src 192.168.0.251 
192.168.1.0/24 dev orange0 proto kernel scope link src 192.168.1.251

The 148.206.49.0/24 is the college intranet of the building. then it goes to network admins knows where and then internet.

tphz · 2 December 2022 11:13

Can you do a test:

Add static routing on yukon
ip route add 192.168.2.0/24 via 192.168.1.254
Then
on e.g. atlantis1, ping to yukon ping 192.168.1.228

Is there an IPFire or some other firewall on atlantis?

mastergeekmx · 8 December 2022 21:16

No, atlantis is not running IPFire but CentOS 7.

And I did some tests and I can’t access computers on ORANGE using the registered domain, but I can by using it’s explicit IP

For example, Yukon (192.168.2.228) is available externally in let’s say yukon.uni.edu via an IP alias at IPFire and then a NAT rerouting rule (like all other devices in orange net.

This is what happens when I try to ping them from an atlantis device:

user@atlantis7:~$ ping 192.168.1.228 -c 4
PING 192.168.1.228 (192.168.1.228) 56(84) bytes of data.
64 bytes from 192.168.1.228: icmp_seq=1 ttl=63 time=0.396 ms
64 bytes from 192.168.1.228: icmp_seq=2 ttl=63 time=0.413 ms
64 bytes from 192.168.1.228: icmp_seq=3 ttl=63 time=0.408 ms
64 bytes from 192.168.1.228: icmp_seq=4 ttl=63 time=0.409 ms

--- 192.168.1.228 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3052ms
rtt min/avg/max/mdev = 0.396/0.406/0.413/0.006 ms

user@atlantis7:~$ ping yukon.uni.edu -c 4
PING yukon.uni.edu ('yukon public IP') 56(84) bytes of data.
64 bytes from yukon.uni.edu ('yukon public IP': icmp_seq=1 ttl=63 time=0.488 ms
64 bytes from yukon.uni.edu ('yukon public IP'): icmp_seq=2 ttl=63 time=0.456 ms
64 bytes from yukon.uni.edu ('yukon public IP'): icmp_seq=3 ttl=63 time=0.457 ms
64 bytes from yukon.uni.edu ('yukon public IP'): icmp_seq=4 ttl=63 time=0.446 ms

--- yukon.uni.edu ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3053ms
rtt min/avg/max/mdev = 0.446/0.461/0.488/0.015 ms

But when I try to access anything using the public domain it times out. Only using the explicit IP it works.

Here I try to make an HTTP request to the webserver in yukon with curl using both the explicit IP and the public domain:

user@atlantis7:~$ curl -I yukon.uni.edu
curl: (28) Failed to connect to yukon.uni.edu port 80: Connection timed out

user@atlantis7:~$ curl -I 192.168.1.228
HTTP/1.1 200 OK
Date: Thu, 08 Dec 2022 20:49:10 GMT
Server: Apache/2.4.54 (Debian)
Last-Modified: Mon, 21 Nov 2022 23:31:31 GMT
ETag: "29d5-5ee03748a6bf5"
Accept-Ranges: bytes
Content-Length: 10709
Vary: Accept-Encoding
Content-Type: text/html

Or trying to get SSH access on it:

user@atlantis7:~$ ssh user@yukon.uni.edu
ssh: connect to host yukon.uni.edu port 22: Connection timed out

user@atlantis7:~$ ssh user@192.168.2.228
user@192.168.1.228's password:

Also, when I use a web browser on any atlantis station to access the orange webpages, pages load slowly and sometimes incomplete

And for good measure, this is the traceroute between atlantis7 and yukon:

user@atlantis7:~$ traceroute 192.168.1.228
traceroute to 192.168.1.228 (192.168.1.228), 30 hops max, 60 byte packets
 1  atlantis (192.168.2.254)  0.282 ms  0.232 ms  0.215 ms
 2  192.168.1.228 (192.168.1.228)  0.412 ms  0.393 ms  0.378 ms

user@atlantis7:~$ traceroute yukon.uni.edu
traceroute to yukon.uni.edu ('yukon public IP'), 30 hops max, 60 byte packets
 1  atlantis (192.168.2.254)  0.291 ms  0.231 ms  0.211 ms
 2  yukon.uni.edu ('yukon public IP')  0.396 ms !H  0.371 ms !H  0.354 ms !H

tphz · 9 December 2022 02:59

Could you try to make a test: e.g. on the atlantis7 computer, add the entry 192.168.2.228 yukon.uni.edu to the hosts file.

Which host is the DNS server running on?

mastergeekmx · 13 December 2022 23:23

DNS is provided by the computing services at college located in another network I guess 1 hop away from RED network. No computer in our lab hosts any kind of DNS service.

I tested putting yukon in /ect/hosts as said and it works if I use the local IP (192.168.2.228 yukon.uni.edu), but when I use the public IP instead of 192.168.2.228 it does not work. traceroute can find the host, but nmap says all ports are closed and connections time out.

If it works, we used to have IPCop as our firewall OS and things worked fine. When we moved to IPFire we tried to rebuild the firewall rules as close as possible.