Hello, On Sun, 17 Nov 2002, Vincent Jaussaud Mailing Listes wrote: > On top of this, defaults gateways for internal servers are unlikely to become > unreachable, since they are on the firewall itself. > Gateways which are likely to colapse, are the ones used by the firewall, eg > ISP1 & ISP2 routers, and this will never be noticed by the internal servers > since they are not directly connected to them. Am I wrong ? Yes, this is a problem, job for user space tools to change the routing settings on failure. > > The server uses the 10.0.0.1 as source when resolving > > route for the reply. Then it depends on the routing rules. > That's good news. So it means that if my routing rules are setup correctly, it > will work. I was afraid of having some packets sent back using a wrong SRC IP :) > > I assume however that this will work only for usual protocol such as http, > smtp, ssh... I'll have to find a workaround for protocols like FTP, if any. > Any idea ? Should not happen for TCP servers but sometimes the UDP servers are not smart enough when used on multihomed servers. See below. > But, just beeing curious, why would rp_filter drop such packets ? Firewall with rp_filter set on internal interfaces expects the traffic to come from the right internal interface (I assume you have the two pubnets configured on different internal interfaces). There is no such problem if the internal interfaces do not use rp_filter. > I mean, we don't really care what link is beeing used for a reply, as soon as > the SRC IP & DST IP are correct. It's likely that ISP1 & ISP2 router won't do > source address validation anyway. Am I wrong ? If the ISPs allow spoofing then while the links are alive there is no problem, it comes when some ISP fails. We should stop using its addresses in this case. > > The transport and the application decide what source IP > > to put in the reply. Then they decide how to call the routing. > > The right thing to do when addresses to both ends are known is > > to feed the routing with saddr and daddr. If callers use 0.0.0.0 > > as saddr when resolving routes, they will hit the multipath > > route which is bad. > > > I'm not sure to understand this point, especially "to feed the routing with > saddr and daddr." > I know we can instruct the routing to use a specific saddr, but what about daddr ? daddr is always used. Some examples (of course, there are other route keys used, not shown here): - TCP connect() for unbound socket uses saddr=0.0.0.0 daddr=REMOTE_IP. The routing then returns the best source IP to use for this connection after creating a connected route in the routing cache. - TCP connect() after bind() uses saddr=LOCAL_IP daddr=REMOTE_IP - TCP listener uses saddr=LOCAL_IP daddr=REMOTE_IP when replying to SYN - UDP can also avoid using 0.0.0.0 as saddr if the socket is bound or when IP_PKTINFO contains local IP information. If the app does not take steps to inform the kernel that this socket is bound to some local IP when sending the packet then 0.0.0.0 is used as src IP for the route lookup (ignoring the fact that this UDP packet has known saddr in iphdr). So, it depends both on transport and on app to feed the routing with the right keys. > Vincent. Regards -- Julian Anastasov <ja@ssi.bg> _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
