From nobody@FreeBSD.org  Sat May  8 11:20:27 2010
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 831E3106564A
	for <freebsd-gnats-submit@FreeBSD.org>; Sat,  8 May 2010 11:20:27 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [69.147.83.33])
	by mx1.freebsd.org (Postfix) with ESMTP id 739558FC13
	for <freebsd-gnats-submit@FreeBSD.org>; Sat,  8 May 2010 11:20:27 +0000 (UTC)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.3/8.14.3) with ESMTP id o48BKQoB001258
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 8 May 2010 11:20:26 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.3/8.14.3/Submit) id o48BKQxM001256;
	Sat, 8 May 2010 11:20:26 GMT
	(envelope-from nobody)
Message-Id: <201005081120.o48BKQxM001256@www.freebsd.org>
Date: Sat, 8 May 2010 11:20:26 GMT
From: Eugen Konkov <kes-kes@yandex.ru>
To: freebsd-gnats-submit@FreeBSD.org
Subject: IP source address for outgoing connections
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         146394
>Category:       kern
>Synopsis:       [vlan] IP source address for outgoing connections
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-net
>State:          feedback
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat May 08 11:30:03 UTC 2010
>Closed-Date:    
>Last-Modified:  Tue May 11 17:30:06 UTC 2010
>Originator:     Eugen Konkov
>Release:        7.1-RELEASE
>Organization:
>Environment:
FreeBSD kes.net.ua 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Sat Jan  3 01:15:39 EET 2009     kes@in.lan:/usr/obj/usr/src/sys/KES_KERN_v7  i386

>Description:
I have RealIP/32 on lo0 interface
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        inet 127.0.0.1 netmask 0xff000000
        inet R.E.A.L netmask 0xffffffff

netstat -nr
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            10.11.19.49        UGS         0 203508809  vlan4

When some do query to web or bind to R.E.A.L response is from 10.11.19.51
because of default route is on that network.

vlan4: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether 00:13:d4:ce:82:16
        inet 10.11.19.51 netmask 0xfffffff8 broadcast 10.11.19.55
        media: Ethernet autoselect (100baseTX <full-duplex,flag0,flag1>)
        status: active
        vlan: 4 parent interface: nfe0

how to force to response from that IP to which query was arrived?
is there 'setfib' like tool? (setip for example)

>How-To-Repeat:
ifconfig lo0 add R.E.A.L1/32
ifconfig lo1 add R.E.A.L2/32
ifconfig rl4 add 10.11.19.49/30
route add default 10.11.19.50

When some program open socket it will use 10.11.19.49 as source address
for outgoing packet. That is impossible to force that program to use
R.E.A.L2 or R.E.A.L1 IP address as souce address for outgoing packets
>Fix:
create tool like setfib, for example:

setfib 1 setip R.E.A.L2 /usr/local/bin/myprogram


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->freebsd-net 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Sat May 8 14:38:10 UTC 2010 
Responsible-Changed-Why:  
Over to maintainer(s). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=146394 
State-Changed-From-To: open->feedback 
State-Changed-By: julian 
State-Changed-When: Sat May 8 09:47:30 PDT 2010 
State-Changed-Why:  
The behaviour you quote as a bug is expected and useful and I don't think it is a bug. 
Any non-bound socket will 'bind' itself to the address of the interface through which the  
outgoing packet will leave. If you do not do this there is no guarantee that the 
client will be able to get to the responding address as it may be on a differnet network. 

Anyhow there are ways to do what you want. 
firstly: what you are talking about will ONLY happen if you do not bind the 
socke to an address, so looking in the config file and binding it will  
fix it. Most programs have an option to do this. I had to do this yesterday with named. 
(though I didn't find such an option in ntpd). 
You need to look at what is going on using sockstat and netstat -aAn 
any socket that has a local address of "*" will have this behaviour. 

If you can't do this then you can use the jail command to force a program that 
does not support binding to be bound. 
Put it in a jail that has the same root as the rest of the system 
but has a forced IP address of that you want. 

Let me know if this solved your problem an dwe can close the bug. 




http://www.freebsd.org/cgi/query-pr.cgi?pr=146394 

From: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= <kes-kes@yandex.ru>
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
 
>Unformatted:
