Hi Nicolas, Thomas! Here is a more detailed description of our scenario:
+--------------+
+---+ | NAS/Roaming | (NAS/Roaming Partner may not be
| 1 | | RadiusServer | part of our Network and can have their
+---+ +--------------+ own Public/Private IP Networks)
|
|
|
+--------------+
| Our |
+-------->-------| FireWall/ |
| | IPSEC |
| | Tunnel |
| | Endpoint |
| +--------------+
| |
| +---+ |
| | 2 | +----+----+
| +---+ | |
| Clients which Clients with
| comes from "direct"
| IPSec Tunnels Internet Access
| | |
| | |
| eth0:1 eth0
| 10.0.0.10 62.62.62.62
| | |
| +--------------+
| | Our |-eth1-<->-[internal AdminLan]
| | RadiusServer |
| +--------------+
| | |
| +---+ eth0:1 eth0
| | 3 | 10.0.0.10 62.62.62.62
| +---+ | |
+-------<----------+---<-----+
1. Packet comes from NAS or from a Roaming Partner, either from internet
or via IPSEC Tunnel, which terminates on "Our Firewall".
2. The Firewall routes the Packet to our Radius Server.
3. The radius server auth/acct local realms and proxies all other realms
to the appropriate foreign radius proxy/server back via "Our Firewall".
If the packet has to go to a partner which needs an IPSEC Tunnel it is
proxied over eth0:1, otherwise over eth0.
That's the point of our problem.
In our case the default gateway points to the public ip_address of the
internal interface of "Our Firewall". For a Proxy Packet the
Packet->src_ipaddr is empty. As the sendmsg function has no src_ipaddr
it uses the default gateway as src_ipaddr for this packet. Therefore the
IPSEC tunnel on "Our Firewall" discards the proxy packet because they
expect the packet from 10.0.0.10 (LeftSide/RightSide IPSEC). Even if the
IPSEC tunnel would allow our packets, the foreign radius server would
silently discard the packet as it uses the wrong src_ipaddr.
In your scenario you are direct connected to the networks where your
proxyserver resides so you don't need to use a default gateway to reach
your servers.
My previously posted patch adds configuration items for the proxy.conf
config file where you can define the ip_addr which should be used for
each Realm.
I would be glad if someone can confirm this as problem and my patch as
the right solution ;-)
For our 2.nd Problem i stated previously in this thread (that the above
scenario is NOT working if eth0:1 is a physical interface) we will
rebuild our test-scenario to post better debugging information.
best regards
Raimund Sacherer
On Wed, 2004-10-20 at 16:34 +0200, Thomas MARCHESSEAU wrote:
> Hi Raimund,
>
> Nicolas and I did some test on proxy forwarding , we use this model :
>
>
>
> CLIENT 172.16.69.1
> |
> vlan 69
> |
> 172.16.69.3 (virtual ip
> handled by keepalived)
> |
> 172.16.69.2 (eth2)
> |
> +---------------------+
> | PROXY with udpfromto|
> | and bind_addr * |
> | ldflag = round_robin|
> +---------------------+
> | |
> eth0 eth3
> 192.168.7.241 10.17.1.243
> | |
> | |
> +-<vlan7>---------+ +-<vlan1017>--+
> | |
> | |
> +------------------+
> +------------------+
> | Radius Srv | | Radius
> Srv |
> | 192.168.7.243 | |
> 10.17.10.242 |
> +------------------+
> +------------------+
>
>
> We hope that it match with your goal .
>
> 1/
> rad_recv: Access-Request packet from host 172.16.69.1:32914, id=15,
> length=77
> User-Name = "[EMAIL PROTECTED]"
> User-Password = "24r3iis"
> NAS-IP-Address = 1.2.3.4
> NAS-Port-Type = xDSL
> NAS-Port = 0
> Sending Access-Request of id 0 to 192.168.7.243:1812
> User-Name = "[EMAIL PROTECTED]"
> User-Password = "24r3iis"
> NAS-IP-Address = 1.2.3.4
> NAS-Port-Type = xDSL
> NAS-Port = 0
> Proxy-State = 0x3135
> rad_recv: Access-Accept packet from host 192.168.7.243:1812, id=0,
> length=103
> Tunnel-Server-Endpoint:0 = "172.16.128.1"
> Tunnel-Assignment-Id:0 = "172.16.128.1"
> Service-Type = Framed-User
> Framed-Protocol = PPP
> Tunnel-Type:0 = L2TP
> Tunnel-Medium-Type:0 = IP
> Tunnel-Password:0 = "secret"
> Proxy-State = 0x3135
> Login OK: [EMAIL PROTECTED]/24r3iis] (from client lodoss port 0)
> Sending Access-Accept of id 15 to 172.16.69.1:32914
> Tunnel-Server-Endpoint:1 = "172.16.128.1"
> Tunnel-Assignment-Id:1 = "172.16.128.1"
> Service-Type = Framed-User
> Framed-Protocol = PPP
> Tunnel-Type:1 = L2TP
> Tunnel-Medium-Type:1 = IP
> Tunnel-Password:1 = "secret"
>
> 2/
> rad_recv: Access-Request packet from host 172.16.69.1:32914, id=13,
> length=77
> User-Name = "[EMAIL PROTECTED]"
> User-Password = "24r3iis"
> NAS-IP-Address = 1.2.3.4
> NAS-Port-Type = xDSL
> NAS-Port = 0
> Sending Access-Request of id 0 to 10.17.1.11:1812
> User-Name = "[EMAIL PROTECTED]"
> User-Password = "24r3iis"
> NAS-IP-Address = 1.2.3.4
> NAS-Port-Type = xDSL
> NAS-Port = 0
> Proxy-State = 0x3133
> rad_recv: Access-Accept packet from host 10.17.1.11:1812, id=0, length=103
> Tunnel-Server-Endpoint:0 = "172.16.128.1"
> Tunnel-Assignment-Id:0 = "172.16.128.1"
> Service-Type = Framed-User
> Framed-Protocol = PPP
> Tunnel-Type:0 = L2TP
> Tunnel-Medium-Type:0 = IP
> Tunnel-Password:0 = "secret"
> Proxy-State = 0x3133
> Login OK: [EMAIL PROTECTED]/24r3iis] (from client lodoss port 0)
> Sending Access-Accept of id 13 to 172.16.69.1:32914
> Tunnel-Server-Endpoint:1 = "172.16.128.1"
> Tunnel-Assignment-Id:1 = "172.16.128.1"
> Service-Type = Framed-User
> Framed-Protocol = PPP
> Tunnel-Type:1 = L2TP
> Tunnel-Medium-Type:1 = IP
> Tunnel-Password:1 = "secret"
>
> As you can see above , the proxy receives response on both Interfaces .
> we dont find any problems with this kind of setup , you might check
> again if its really a problem with Freeradius or your network config [
> iptables , routing problems, tcpwrapper ... ]
> We re using freeradius 1.0.1 + udpfromto patch, on debian sid + 2.4.26-grsec
>
> Regards
> Nicolas , Thomas .
>
>
>
>
>
>
> Raimund Sacherer wrote:
>
> >Here is our Scenario which is working now:
> >
> >Some Partners depend on an IPSec tunnel.
> >
> >
> > +--------------+
> > | Our |
> > | RadiusServer |
> > +--------------+
> > | |
> > eth0:1 eth0
> > 10.0.0.10 62.62.62.62
> > | |
> > | |
> > | |
> > | |
> > +-<IPSec Tunnel>--+ +-<Internet>--+
> > | |
> > | |
> >+------------------+ +------------------+
> >| Other Radius Srv | | Other Radius Srv |
> >| from RaomPartner | | from RaomPartner |
> >+------------------+ +------------------+
> >
> >
> >
> >If eth0:1 is another physical device (e.g. eth1) then it is NOT working.
> >Netstat -uan displays that the radius server is listening on all
> >(interfaces/ip-addresses) on port 1814.
> >
> >Sending an request-package to our Roaming Partner is working (from the
> >correct IP also, but the respond from the Roaming Partner is not
> >recognized by our Radius Server but tcpdump shows that the Roaming
> >Partner sends an Respond (either Access Reject or Access Accept) and
> >that it's incoming on our interface (eth1).
> >
> >If i move the IP from eth1 to eth0:1 as an alias, all is working again.
> >
> >Strange is, if i locally connect with netcat to eth1 udp port 1814, our
> >Radius Server IS answering.
> >
> >I do not really know where the problem exists, it works with IPAliases,
> >but i would feel much more secure if we can find a working solution for
> >eth1 also.
> >
> >Here is an example from our configuration:
> >
> >--- SNIP radiusd.conf---
> >#bind_address = *
> >#bind_address = 10.0.0.10
> >
> >listen {
> > ipaddr = 10.0.0.10
> > type=auth
> >}
> >
> >listen {
> > ipaddr = 10.0.0.10
> > type=acct
> >}
> >
> >listen {
> > ipaddr = 62.62.62.62
> > type=auth
> >}
> >
> >listen {
> > ipaddr = 62.62.62.62
> > type=acct
> >}
> >--- SNIP ---
> >
> >--- SNIP proxy.conf---
> >proxy server {
> > synchronous = no
> > retry_delay = 10
> > retry_count = 6
> > dead_time = 0
> > default_fallback = no
> > post_proxy_authorize = no
> > proxyip = 62.62.62.62
> >}
> >
> >realm veryFrightenedRoamingPartner {
> > type = radius
> > authhost = 172.172.172.172:1812
> > accthost = 172.172.172.172:1813
> > proxyip = 10.10.10.10
> > secret = "<SECRET>"
> >}
> >--- SNIP ---
> >
> >
> >On Tue, 2004-10-12 at 16:47 +0200, Raimund Sacherer wrote:
> >
> >
> >>Hi,
> >>
> >>i compiled freeradius (1.0.1) with the UDPFROMTO configure option and i
> >>applied the patch from nicolas
> >>(http://www.mail-archive.com/[EMAIL PROTECTED]/msg09417.html)
> >>and now receiving/sending local auth/acct packets with more than one ip
> >>address works as expected.
> >>
> >>There where two problems with proxying, first, i listen to 2 ip
> >>addresses, if those where on different interfaces (eth0/eth1) it is not
> >>working, the problem is, the packet is sent to the roamingpartner, but
> >>the response is not recognized by freeradius (where a local test with
> >>netcat is recognized), but i can see it clearly with tcpdump.
> >>
> >>It works well if these 2 ip addresses are on the same interface (with
> >>ip-alias).
> >>
> >>The second problem with proxying is that it used the interface which was
> >>defined to send data to the standard gateway as the src-ip address for
> >>sending proxy-packets.
> >>
> >>That was a problem for our scenario, as we have roamingpartners which
> >>are listening for our packets on the first ip and others on the other,
> >>therefore i patched freeradius to except in the realm-configuration
> >>another parameter which tells the proxy_send method which src-ip it
> >>should use to send the data, this is working and solved this second
> >>problem, i have the patch attached and would be happy if it made it's
> >>way into the source.
> >>
> >>Technical Detail about the Patch:
> >>1. Add Proxy IP Address to CONF_PARSER proxy_config[], MAIN_CONFIG_T and
> >>into the REALM struct.
> >>
> >>2. In generate_realms check if there is a proxy_ip set for this realm or
> >>a global (mainconfig.proxy_ipaddr) one. If so, apply it.
> >>
> >>3. In proxy_send check if in the REALM is an IP address set, if so, set
> >>it in request->proxy->src_ipaddr so we have a src IP.
> >>
> >>
> >>--- snip ---
> >>
> >>--- freeradius-1.0.0-pre2/src/include/radiusd.h 2004-10-04
> >>10:27:37.000000000 +0200
> >>+++ /tmp/freeradius-1.0.0-pre2-ewave/src/include/radiusd.h 2004-10-12
> >>12:45:24.353286104 +0200
> >>@@ -124,6 +124,7 @@
> >> char server[64];
> >> char acct_server[64];
> >> uint32_t ipaddr; /* authentication */
> >>+ uint32_t proxy_ipaddr; /* proxy via interface, rsacherer */
> >> uint32_t acct_ipaddr;
> >> u_char secret[32];
> >> time_t last_reply; /* last time we saw a packet */
> >>@@ -194,6 +195,7 @@
> >> int proxy_retry_count;
> >> int proxy_retry_delay;
> >> int proxy_fallback;
> >>+ char *proxy_ipaddr; /* proxy via interface, rsacherer */
> >> int reject_delay;
> >> int status_server;
> >> int max_request_time;
> >>--- freeradius-1.0.0-pre2/src/main/mainconfig.c 2004-10-04
> >>10:27:38.000000000 +0200
> >>+++ /tmp/freeradius-1.0.0-pre2-ewave/src/main/mainconfig.c 2004-10-12
> >>12:45:16.593465776 +0200
> >>@@ -76,6 +79,7 @@
> >> { "dead_time", PW_TYPE_INTEGER, 0, &mainconfig.proxy_dead_time,
> >>Stringify(DEAD_TIME) },
> >> { "post_proxy_authorize", PW_TYPE_BOOLEAN, 0,
> >>&mainconfig.post_proxy_authorize, "yes" },
> >> { "wake_all_if_all_dead", PW_TYPE_BOOLEAN, 0,
> >>&mainconfig.wake_all_if_all_dead, "no" },
> >>+ { "proxyip", PW_TYPE_STRING_PTR, 0, &mainconfig.proxy_ipaddr, NULL },
> >> { NULL, -1, 0, NULL, NULL }
> >> };
> >>
> >>@@ -347,7 +351,7 @@
> >> CONF_SECTION *cs;
> >> REALM *my_realms = NULL;
> >> REALM *c, **tail;
> >>- char *s, *t, *authhost, *accthost;
> >>+ char *s, *t, *authhost, *accthost, *proxy_ipaddr;
> >> char *name2;
> >>
> >> tail = &my_realms;
> >>@@ -369,6 +373,28 @@
> >> c->secret[0] = '\0';
> >>
> >> /*
> >>+ * Check first if a realm IP is set, if not
> >>+ * check the Mainconfig item, else it means 0 ;-)
> >>+ * rsacherer
> >>+ */
> >>+ if ((proxy_ipaddr = cf_section_value_find(cs, "proxyip")) == NULL) {
> >>+ proxy_ipaddr = mainconfig.proxy_ipaddr;
> >>+ }
> >>+
> >>+ if (proxy_ipaddr == NULL) {
> >>+ c->proxy_ipaddr = htonl(INADDR_NONE);
> >>+ } else {
> >>+ c->proxy_ipaddr = ip_getaddr(proxy_ipaddr);
> >>+ if (c->proxy_ipaddr == htonl(INADDR_NONE)) {
> >>+ radlog(L_ERR, "%s[%d]: Host %s not found",
> >>+ filename, cf_section_lineno(cs),
> >>+ proxy_ipaddr);
> >>+ return -1;
> >>+ }
> >>+ }
> >>+
> >>+
> >>+ /*
> >> * No authhost means LOCAL.
> >> */
> >> if ((authhost = cf_section_value_find(cs, "authhost")) == NULL) {
> >>--- freeradius-1.0.0-pre2/src/main/proxy.c 2004-10-04 10:27:38.000000000
> >>+0200
> >>+++ /tmp/freeradius-1.0.0-pre2-ewave/src/main/proxy.c 2004-10-12
> >>12:45:16.701449360 +0200
> >>@@ -430,6 +430,14 @@
> >> request->proxy->timestamp = request->timestamp - (delaypair ?
> >>delaypair->lvalue : 0);
> >>
> >> /*
> >>+ * Add the proxy_ipaddr as the source ip address, if one is set
> >>+ * rsacherer
> >>+ */
> >>+ if (realm->proxy_ipaddr != htonl(INADDR_NONE)) {
> >>+ request->proxy->src_ipaddr = realm->proxy_ipaddr;
> >>+ }
> >>+
> >>+ /*
> >> * Do pre-proxying
> >> */
> >> rcode = module_pre_proxy(request);
> >>
> >>
> >>
>
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
signature.asc
Description: This is a digitally signed message part
