Routing table to almost the same subnet

Redbob

Hi,
I have a Squid installed in a Ubuntu server. This is routing table and it's running very well:

usrproxy@srvproxy3-mt:~$ ip addr
1: lo: 
2: eth0: inet 172.24.1.12/24 brd 172.24.1.255 scope global eth0
3: eth1: inet 172.24.3.19/22 brd 172.24.3.255 scope global eth1

Destino         Roteador        MáscaraGen.    Opções Métrica Ref   Uso Iface
0.0.0.0         172.24.1.6      0.0.0.0         UG    0      0        0 eth0
172.24.0.0      0.0.0.0         255.255.252.0   U     0      0        0 eth1
172.24.1.0      0.0.0.0         255.255.255.0   U     0      0        0 eth0
172.24.4.0      172.24.0.1      255.255.254.0   UG    0      0        0 eth1
172.24.6.0      172.24.0.1      255.255.254.0   UG    0      0        0 eth1
172.24.8.0      172.24.0.1      255.255.254.0   UG    0      0        0 eth1
172.24.10.0     172.24.0.1      255.255.254.0   UG    0      0        0 eth1
172.24.12.0     172.24.0.1      255.255.254.0   UG    0      0        0 eth1
172.24.20.0     172.24.0.1      255.255.254.0   UG    0      0        0 eth1
172.24.32.0     172.24.0.1      255.255.254.0   UG    0      0        0 eth1
172.24.36.0     172.24.0.1      255.255.254.0   UG    0      0        0 eth1
172.24.40.0     172.24.0.1      255.255.254.0   UG    0      0        0 eth1
172.24.44.0     172.24.0.1      255.255.254.0   UG    0      0        0 eth1
172.24.48.0     172.24.0.1      255.255.254.0   UG    0      0        0 eth1
172.24.52.0     172.24.0.1      255.255.254.0   UG    0      0        0 eth1

I'm trying to do the same to a PfSense firewall, but I can't:

*** Welcome to pfSense 2.4.4-RELEASE-p3 (amd64) on srvfw02-mt ***

 WAN (wan)       -> xn0        -> v4: 172.24.1.7/24
 LAN (lan)       -> xn1        -> v4: 172.24.3.18/24
 CFTV (opt1)     -> xn2        -> v4: 192.168.0.1/24

Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            172.24.1.6         UGS         xn0
localhost          link#2             UH          lo0
172.24.0.1         fa:79:c8:24:1d:5e  UHS         xn1
172.24.1.0/24      link#5             U           xn0
172.24.1.7         link#5             UHS         lo0
172.24.3.0/24      link#6             U           xn1
srvfw02-mt         link#6             UHS         lo0
172.24.4.0/23      172.24.0.1         UGS         xn1
172.24.12.0/23     172.24.0.1         UGS         xn1
172.24.20.0/23     172.24.0.1         UGS         xn1
192.168.0.0/24     link#7             U           xn2
192.168.0.1        link#7             UHS         lo0

Nobody out of 172.24.3.0/24 is getting 172.24.3.18!!!

C:\Users\mt6503.JFMT>tracert 172.24.3.18

Rastreando a rota para 172.24.3.18 com no máximo 30 saltos

  1     1 ms     1 ms     1 ms  172.24.12.3
  2     *        *        *     Esgotado o tempo limite do pedido.
  3     *        *        *     Esgotado o tempo limite do pedido.

...but I cat do it to the former proxy:

C:\Users\mt6503.JFMT>tracert 172.24.3.19

Rastreando a rota para srvproxy3-mt.mt.trf1.gov.br [172.24.3.19]
com no máximo 30 saltos:

  1     1 ms     1 ms     1 ms  172.24.12.3
  2     1 ms     1 ms     1 ms  srvproxy3-mt.mt.trf1.gov.br [172.24.3.19]

Any clues?

Redbob

I got it! Just created a firewall rule to allow ICMP Echo Request from any to any in LAN interface!!! See How to allow ping on pfSense firewall?

JeGr

Your ubuntu server will get in quite a pinch with that routing table:

172.24.0.0      0.0.0.0         255.255.252.0   U     0      0        0 eth1
172.24.1.0      0.0.0.0         255.255.255.0   U     0      0        0 eth0

Those are clearly overlapping and even configured to separate interfaces. That's no nice way to route. If you ever have some 172.24.1.x addresses on eth1 those won't work. That's a thing we call "accident/disaster in the making" at work ;)