# FreeBSD does not redirect to new host as the ICMP redirect from Firewall



## switchaphon (Jun 5, 2013)

My FreeBSD 8.2 point gateway to 192.168.1.25. 192.168.1.25 is the gateway where redirect traffic to 192.168.1.1.

When I test `ping` from FreeBSD to 8.8.8.8, I got below message on screen


```
TEST# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
92 bytes from 122.248.120.25: Redirect Host(New addr: 122.248.120.1)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 3bf7   0 0000  40  01 3b8a 122.248.120.32  8.8.8.8 
92 bytes from 122.248.120.25: Redirect Host(New addr: 122.248.120.1)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 3bfd   0 0000  40  01 3b84 122.248.120.32  8.8.8.8**
```
 
And I got the `tcpdump` for ICMP as below:


```
06:19:35.144386 IP TEST.NTTC.COM.MM > google-public-dns-a.google.com: ICMP echo request, id 13094, seq 0, length 64
06:19:35.144841 IP 122.248.120.25 > TEST.NTTC.COM.MM: ICMP redirect google-public-dns-a.google.com to host 122.248.120.1, length 92
06:19:36.155552 IP TEST.NTTC.COM.MM > google-public-dns-a.google.com: ICMP echo request, id 13094, seq 1, length 64
06:19:36.156137 IP 122.248.120.25 > TEST.NTTC.COM.MM: ICMP redirect google-public-dns-a.google.com to host 122.248.120.1, length 92
```


As I checked from Google, all configuration about redirect is configured as below:


```
TEST# sysctl -a | grep redirect
net.inet.ip.redirect: 1
net.inet.icmp.log_redirect: 0
net.inet.icmp.drop_redirect: 0
net.inet6.ip6.redirect: 1
```

But when I test with CentOS 5.8, `ping` is reachable and screen show as below:


```
bash-3.2# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 192.168.1.25: icmp_seq=1 Redirect Host(New nexthop: 192.168.1.1)**
64 bytes from 8.8.8.8: icmp_seq=2 ttl=49 time=75.8 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=49 time=76.9 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=49 time=75.8 ms
```

And I got the `tcpdump` for ICMP as below:


```
02:55:34.098230 IP 122.248.120.32 > google-public-dns-a.google.com: ICMP echo request, id 17419, seq 1, length 64
02:55:34.098629 IP 122.248.120.25 > 122.248.120.32: ICMP redirect google-public-dns-a.google.com to host 122.248.120.1, length 92
02:55:35.098029 IP 122.248.120.32 > google-public-dns-a.google.com: ICMP echo request, id 17419, seq 2, length 64
02:55:35.174478 IP google-public-dns-a.google.com > 122.248.120.32: ICMP echo reply, id 17419, seq 2, length 64*
```

And the configuration about redirect as below:


```
bash-3.2# /sbin/sysctl -a | grep redirect |grep ipv4
net.ipv4.conf.eth0.send_redirects = 1
net.ipv4.conf.eth0.secure_redirects = 1
net.ipv4.conf.eth0.accept_redirects = 1
net.ipv4.conf.lo.send_redirects = 1
net.ipv4.conf.lo.secure_redirects = 1
net.ipv4.conf.lo.accept_redirects = 1
net.ipv4.conf.default.send_redirects = 1
net.ipv4.conf.default.secure_redirects = 1
net.ipv4.conf.default.accept_redirects = 1
net.ipv4.conf.all.send_redirects = 1
net.ipv4.conf.all.secure_redirects = 1
net.ipv4.conf.all.accept_redirects = 1
net.ipv4.route.redirect_silence = 20480
net.ipv4.route.redirect_number = 9
net.ipv4.route.redirect_load = 20
```

Any idea about FreeBSD, it looks like FreeBSD receives redirect information but does not redirect as the information that it got and still send to old direction. Is there any workaround or solution to solve this issue. Thank you in advance.

Un ^^


----------



## SirDice (Jun 5, 2013)

switchaphon said:
			
		

> My FreeBSD 8.2



Please upgrade to 8.3 or the upcoming 8.4. FreeBSD 8.2 has been end-of-life since July 2012.

http://www.freebsd.org/security/unsupported.html

As for allowing ICMP redirects, don't. There's a reason this is blocked by default. You will open yourself up for some sophisticated attacks. 



> gateway to 192.168.1.25. 192.168.1.25 is the gateway where redirect traffic to 192.168.1.1.


Why not simply set the gateway to the correct IP; 192.168.1.1?


----------



## switchaphon (Jun 5, 2013)

Thank you, for you reply @SirDice!



			
				SirDice said:
			
		

> Why not simply set the gateway to the correct IP; 192.168.1.1?



Because of the limitation and condition on networking issue, our gateway firewall (.25) which connects to 2 ISPs for Internet access, 192.168.1.1 is the gateway of one ISP. The reason that we need to point to .25 instead direct to .1, because redundant condition. In case link to this carrier (.1) down, firewall will redirect to another ISP automatically. That's the reason we do not want to point gateway direct to one ISP only.

Then we would like to know whether there is the work around to solve this issue because as tested CentOS is work with this condition.

Thank you!


----------



## SirDice (Jun 5, 2013)

switchaphon said:
			
		

> Because of the limitation and condition on networking issue, our gateway firewall (.25) which connects to 2 ISPs for Internet access, 192.168.1.1 is the gateway of one ISP.


That would mean both sides of the firewall are in the 192.168.1/24 network?

Depending on the firewall you could use VRRP to create a 'virtual' IP address that's connected to both firewalls. Set that address as the default gateway. Whatever happens after the firewall isn't a concern of the clients.

Allowing ICMP redirects not only allows hackers to "redirect" network traffic to a bad host it also generates additional network traffic and latency.


----------



## switchaphon (Jun 6, 2013)

SirDice said:
			
		

> That would mean both sides of the firewall are in the 192.168.1/24 network?



Both connection to both ISP (A and B) is different network. Normally, traffic mainly go through ISP A by ICMP Redirect technique. Firewall will check availability of that primary link to A. In case link between firewall and ISP A down, Firewall will connect to internet via ISP B by NAT technique . That why we do not want set the default gateway to .1 direct. 



			
				SirDice said:
			
		

> Depending on the firewall you could use VRRP to create a 'virtual' IP address that's connected to both firewalls. Set that address as the default gateway. Whatever happens after the firewall isn't a concern of the clients.



As your recommend about Virtual IP address, we can not apply that solution in to our condition because both connection of Firewall are connect to different network between ISP A and B.




			
				SirDice said:
			
		

> Allowing ICMP redirects not only allows hackers to "redirect" network traffic to a bad host it also generates additional network traffic and latency.



We understand that the ICMP redirect is two-edged sword but I just want to confirm that there is the way to enable FreeBSD receive and work with ICMP Redirect as CentOS or not. Does it absolutely not possible? Otherwise we need to re-install our server and change OS.    


Thank you for your suggestion!!.


----------



## switchaphon (Jun 6, 2013)

Is there any idea to fix it out!????


----------



## throAU (Jun 10, 2013)

You are best off "fixing" it by fixing the architecture of your network.

It looks like there is a sysctl for tweaking ICMP redirects for IPv6, but I don't see one for IPv4.

What you probably actually want to do is run a single gateway on your LAN with 3 interfaces leading to 2 different ISPs (i.e., it has ports for LAN, WAN1, and WAN2 - and use costs for deciding which link to route through).

Futzing around with ICMP redirects is a bit of a bodge.

If you have a layer 3 switch, you can maybe use THAT as your LAN gateway and have that route off to two different routers (each on it's own VLAN and IP subnet) as required.

Installing CentOS to use ICMP redirect won't really "fix" the problem.

Alternatively - do your routers support RIP or another protocol?  You could maybe set up RIP (or even better, OSPF if supported) on FreeBSD and have it talk to the router(s) and learn which route(s) are up/preferable as they go up/down?


----------



## switchaphon (Jun 11, 2013)

Thank you for your all help. The root cause is my fault that enabled 
	
	



```
gateway_enable="YES"
```
 in /etc/rc.conf that caused FreeBSD to not accept ICMP Redirect. Once I comment it out and restart the server, my FreeBSD can go through to the Internet via the redirect gateway.

Again, Thank you for your help. ^^


----------

