From owner-freebsd-net@FreeBSD.ORG Tue May 11 17:30:09 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F456106570C for ; Tue, 11 May 2010 17:30:09 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4CEFD8FC08 for ; Tue, 11 May 2010 17:30:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o4BHU8Uu096450 for ; Tue, 11 May 2010 17:30:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4BHU8eL096445; Tue, 11 May 2010 17:30:08 GMT (envelope-from gnats) Date: Tue, 11 May 2010 17:30:08 GMT Message-Id: <201005111730.o4BHU8eL096445@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= Cc: Subject: Re: kern/146394: [vlan] IP source address for outgoing connections X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 17:30:09 -0000 The following reply was made to PR kern/146394; it has been noted by GNATS. From: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= To: bug-followup@FreeBSD.org, kes-kes@yandex.ru Cc: Subject: Re: kern/146394: [vlan] IP source address for outgoing connections Date: Tue, 11 May 2010 20:05:36 +0300 jFo> Synopsis: [vlan] IP source address for outgoing connections jFo> State-Changed-From-To: open->feedback jFo> State-Changed-By: julian jFo> State-Changed-When: Sat May 8 09:47:30 PDT 2010 jFo> State-Changed-Why: jFo> The behaviour you quote as a bug is expected and useful and I don't think it is a bug. jFo> Any non-bound socket will 'bind' itself to the address of the interface through which the jFo> outgoing packet will leave. If you do not do this there is no guarantee that the jFo> client will be able to get to the responding address as it may be on a differnet network. jFo> Anyhow there are ways to do what you want. jFo> firstly: what you are talking about will ONLY happen if you do not bind the jFo> socke to an address, so looking in the config file and binding it will jFo> fix it. Most programs have an option to do this. I had to do this yesterday with named. jFo> (though I didn't find such an option in ntpd). jFo> You need to look at what is going on using sockstat and netstat -aAn jFo> any socket that has a local address of "*" will have this behaviour. jFo> If you can't do this then you can use the jail command to force a program that jFo> does not support binding to be bound. jFo> Put it in a jail that has the same root as the rest of the system jFo> but has a forced IP address of that you want. jFo> Let me know if this solved your problem an dwe can close the bug. Actually your suggestion (jail), not mine (setip tool) will not resolve the problem. 192.168.0.0/24 ---->[192.168.0.1/24](rl0)-(KERNEL)-(rl1)(192.168.1.1/24)<----192.168.1.0/24 now if 192.168.0.7 will enable connection to 192.168.1.1:80 it will get answer from 192.168.0.1:80 this seems like spoofing =( and some services like mpd<-->radiusd in this situations will fail: response is from untrusted source and md5 chechsum mismatch I agree with you, that I can force daemon to bind to some IP, but in this situation bind *.1812 (or any other service) seems useless despite on in 99% of cases it works fine. jFo> Any non-bound socket will 'bind' itself to the address of the interface through which the jFo> outgoing packet will leave. If you do not do this there is no guarantee that the jFo> client will be able to get to the responding address as it may be on a differnet network. This is ok, for packets when connection is negitiated from router to client, but in situations when client do connection to 192.168.1.1 it must get response from 192.168.1.1 and not from any other machine. Do you agree? Router do connections to lan: So connections from ROUTER to 192.168.0.0/24 will have 192.168.0.1 IP in packets as source address So connections from ROUTER to 192.168.1.0/24 will have 192.168.1.1 IP in packets as source address Router is response to lan: So in connections from CLIENT to router. Router must response from that IP to which client have established connection Case 1: query: 192.168.0.7 -> 192.168.0.1 response: 192.168.0.1 -> 192.168.0.7 Case 2: query: 192.168.0.7 -> 192.168.1.1 response: 192.168.1.1 -> 192.168.0.7 So if client can establish connection to IP from other net he MUST get response from that IP! If client is not allowed to establish connection to IP from other net it MUST not get any response packet at all (Except maybe icmp: host is unreachable or etc.) bring to notice: if client can establish connection to IP from other net it CAN get response from that IP so router MUST resonse from that IP to which client establish connection and ONLY if router establish connection itself it MUST, as you said: jFo> 'bind' itself to the address of the interface through which the outgoing packet will leave Look at this example: R.E.A.L/32 (lo0) 192.168.0.0/24 ---->[192.168.0.1/24](rl0)-(ROUTER0)-(rl1)(192.168.1.1/24) | | | | 192.168.0.7/24 192.168.1.7/24 (rl1) (rl0) (ROUTER1) (ROUTER2) (rl0) (rl1) SOME.REAL.IP.1 SOME.REAL.IP.2 \ / \-------------------- CLIENT --------------------------/ 192.168.0.1 is allowed on ROUTER1 and is nated to SOME.REAL.IP.1 192.168.1.1 is allowed on ROUTER2 and is nated to SOME.REAL.IP.2 on ROUTER1: route add R.E.A.L/32 192.168.0.1 on ROUTER2: route add R.E.A.L/32 192.168.1.1 on ROUTER0: there two default gateways with equal costs 0/0 192.168.0.7 0/0 192.168.1.7 Now as you said: jFo> 'bind' itself to the address of the interface through which the outgoing packet will leave if CLIENT establish connection to R.E.A.L it will get 50% packet response from SOME.REAL.IP.1 and 50% from SOME.REAL.IP.2 %-) also because of NAT on ROUTER1 and ROUTER2 we will have resource leak tcpdump on CLIENT willshow: CLIENT -> R.E.A.L SOME.REAL.IP.1 -> CLIENT CLIENT -> R.E.A.L SOME.REAL.IP.2 -> CLIENT Bring notice that that response packet have different IPs! from resource we are establish connection. In 99% this work, 1% -- WILL NOT! As I have said: >>So if client can establish connection to IP from other net he MUST get response from that IP! in this situations everithing is expected: 1. No resource leak on ROUTER1 and ROUTER2 and maybe ROUTER3... 2. tcpdump on client: CLIENT -> R.E.A.L R.E.A.L -> CLIENT CLIENT -> R.E.A.L R.E.A.L -> CLIENT Another case: Router establish connection to CLIENT This is the case your rule MUST apply: jFo> 'bind' itself to the address of the interface through which the outgoing packet will leave jFo> http://www.freebsd.org/cgi/query-pr.cgi?pr=146394 -- Eugen Konkov mailto:kes-kes@yandex.ru