Forwarding UDP packets
Hi,
Recently I've been faced with an odd problem. I setup a pptp link to my
network from my friend's XP machine. While the link functions fine
(both ends can ping each other, etc), there is one problem with it. I
cannot get any broadcast packets through the link. I receive them on
the tun0 interface, but no matter what I try i can't get them out of the
fxp0 interface. I cannot get them to go the other way either. I know
this is against standards, as they suggest routers should not forward
broadcast packets, but I would still like to have this ability.
Did anyone ever write a patch of some sort or maybe found a tool that
does this type of thing?
(many people suggested natd, and after playing with that i was able to
redirect some bcast packets from tun0 to 1 host on my lan. I was not
able to do that in the other direction, however.)
I've found an old post on the hackers list by Jonathan Chen that
included a patch to enable this kind of functionality. I applied it to
my 4.6-RELEASE kernel and it didn't do anything but add a sysctl
variable. Any help would be greatly appreciated.
Here is that post:
---
On FreeBSD -CURRENT and -STABLE, packets to broadcast addresses are not
forwarded. For instance, if I have a FreeBSD router with interfaces
192.168.1.1 and 192.168.2.1, and I send packets from 192.168.1.2 to
192.168.2.255, the packets are dropped to the floor. IMO, this is wrong...
but I haven't consulted all the RFC's so I'm not sure if some standard out
there calls for it. In any case, the following patch creates a sysctl knob
to turn on or off this feature (since it can be considered a security risk
by some). I just want to ask around in case I turned out to be doing
something incredibly evil. Comments?
-Jon
Index: in.h
===
RCS file: /export/ncvs/src/sys/netinet/in.h,v
retrieving revision 1.55
diff -u -r1.55 in.h
--- in.h 2001/06/15 00:37:27 1.55
+++ in.h 2001/08/09 15:12:19
@@ -452,7 +452,8 @@
#define IPCTL_FASTFORWARDING 14 /* use fast IP forwarding code */
#define IPCTL_KEEPFAITH 15 /* FAITH IPv4->IPv6 translater ctl */
#define IPCTL_GIF_TTL 16 /* default TTL for gif encap packet */
-#define IPCTL_MAXID 17
+#define IPCTL_FORWARD_BROADCAST 18 /* forward broadcast packets */
+#define IPCTL_MAXID 18
#define IPCTL_NAMES { \
{ 0, 0 }, \
Index: ip_input.c
===
RCS file: /export/ncvs/src/sys/netinet/ip_input.c,v
retrieving revision 1.174
diff -u -r1.174 ip_input.c
--- ip_input.c 2001/06/23 17:17:58 1.174
+++ ip_input.c 2001/08/09 15:33:59
@@ -103,6 +103,10 @@
SYSCTL_INT(_net_inet_ip, IPCTL_FORWARDING, forwarding, CTLFLAG_RW,
&ipforwarding, 0, "Enable IP forwarding between interfaces");
+int ipforward_broadcast = 0;
+SYSCTL_INT(_net_inet_ip, IPCTL_FORWARD_BROADCAST, forward_broadcast,
CTLFLAG_RW,
+&ipforward_broadcast, 0, "Enable broadcast packets when forwarding
IP packets");
+
static int ipsendredirects = 1; /* XXX */
SYSCTL_INT(_net_inet_ip, IPCTL_SENDREDIRECTS, redirect, CTLFLAG_RW,
&ipsendredirects, 0, "Enable sending IP redirects");
@@ -1684,7 +1688,8 @@
}
error = ip_output(m, (struct mbuf *)0, &ipforward_rt,
- IP_FORWARDING, 0);
+ IP_FORWARDING|
+ (ipforward_broadcast?IP_ALLOWBROADCAST:0), 0);
if (error)
ipstat.ips_cantforward++;
else {
--
Anthony Volodkin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: Forwarding UDP packets
I use poptop+the pppd that is included with 4.6-RELEASE. On the XP
side, my friend just sets up a "Virtual Private Networking Connection"
using the native XP client.
Here are my /etc/ppp/options, if you wanted protocol info:
lock
debug
auth
proxyarp
+chap
+chapms
+chapms-v2
and the relevant portion of ppp.conf:
pptp:
enable chap
enable proxy
set ifaddr 192.168.1.100 192.168.2.200-192.168.2.205 255.255.255.0
>what method of doing pptp are you using?
>
>
>On Wed, 26 Jun 2002, Anthony Volodkin wrote:
>
>
>
>>Hi,
>>
>>Recently I've been faced with an odd problem. I setup a pptp link to my
>>network from my friend's XP machine. While the link functions fine
>>(both ends can ping each other, etc), there is one problem with it. I
>>cannot get any broadcast packets through the link. I receive them on
>>the tun0 interface, but no matter what I try i can't get them out of the
>>fxp0 interface. I cannot get them to go the other way either. I know
>>this is against standards, as they suggest routers should not forward
>>broadcast packets, but I would still like to have this ability.
>>
>>Did anyone ever write a patch of some sort or maybe found a tool that
>>does this type of thing?
>>(many people suggested natd, and after playing with that i was able to
>>redirect some bcast packets from tun0 to 1 host on my lan. I was not
>>able to do that in the other direction, however.)
>>
>>I've found an old post on the hackers list by Jonathan Chen that
>>included a patch to enable this kind of functionality. I applied it to
>>my 4.6-RELEASE kernel and it didn't do anything but add a sysctl
>>variable. Any help would be greatly appreciated.
>>
>>Here is that post:
>>
>>---
>>
>>On FreeBSD -CURRENT and -STABLE, packets to broadcast addresses are not
>>forwarded. For instance, if I have a FreeBSD router with interfaces
>>192.168.1.1 and 192.168.2.1, and I send packets from 192.168.1.2 to
>>192.168.2.255, the packets are dropped to the floor. IMO, this is wrong...
>>but I haven't consulted all the RFC's so I'm not sure if some standard out
>>there calls for it. In any case, the following patch creates a sysctl knob
>>to turn on or off this feature (since it can be considered a security risk
>>by some). I just want to ask around in case I turned out to be doing
>>something incredibly evil. Comments?
>>
>>-Jon
>>
>>Index: in.h
>>===
>>RCS file: /export/ncvs/src/sys/netinet/in.h,v
>>retrieving revision 1.55
>>diff -u -r1.55 in.h
>>--- in.h 2001/06/15 00:37:27 1.55
>>+++ in.h 2001/08/09 15:12:19
>>@@ -452,7 +452,8 @@
>> #define IPCTL_FASTFORWARDING 14 /* use fast IP forwarding code */
>> #define IPCTL_KEEPFAITH 15 /* FAITH IPv4->IPv6 translater ctl */
>> #define IPCTL_GIF_TTL 16 /* default TTL for gif encap packet */
>>-#define IPCTL_MAXID 17
>>+#define IPCTL_FORWARD_BROADCAST 18 /* forward broadcast packets */
>>+#define IPCTL_MAXID 18
>>
>> #define IPCTL_NAMES { \
>> { 0, 0 }, \
>>Index: ip_input.c
>>===
>>RCS file: /export/ncvs/src/sys/netinet/ip_input.c,v
>>retrieving revision 1.174
>>diff -u -r1.174 ip_input.c
>>--- ip_input.c 2001/06/23 17:17:58 1.174
>>+++ ip_input.c 2001/08/09 15:33:59
>>@@ -103,6 +103,10 @@
>> SYSCTL_INT(_net_inet_ip, IPCTL_FORWARDING, forwarding, CTLFLAG_RW,
>> &ipforwarding, 0, "Enable IP forwarding between interfaces");
>>
>>+int ipforward_broadcast = 0;
>>+SYSCTL_INT(_net_inet_ip, IPCTL_FORWARD_BROADCAST, forward_broadcast,
>>CTLFLAG_RW,
>>+&ipforward_broadcast, 0, "Enable broadcast packets when forwarding
>>IP packets");
>>+
>> static int ipsendredirects = 1; /* XXX */
>> SYSCTL_INT(_net_inet_ip, IPCTL_SENDREDIRECTS, redirect, CTLFLAG_RW,
>> &ipsendredirects, 0, "Enable sending IP redirects");
>>@@ -1684,7 +1688,8 @@
>> }
>>
>> error = ip_output(m, (struct mbuf *)0, &ipforward_rt,
>>- IP_FORWARDING, 0);
>>+ IP_FORWARDING|
>>+ (ipforward_broadcast?IP_ALLOWBROADCAST:0), 0);
>> if (error)
>>ipstat.ips_cantforward++;
>> else {
>>
>>
>>--
>>Anthony Volodkin
>>
>>
>>To Unsubscribe: send mail to [EMAIL PROTECTED]
>>with "unsubscribe freebsd-net" in the body of the message
>>
>>
>>
>
>
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
/usr/lib/libtelnet.a missing on 4.6?
Hi, I'm trying to build the latest KAME SNAP, and the build fails, because /usr/lib/libtelnet.a is missing on a freshly installed 4.6-RELEASE system (installed from CD). None of our 4.6 systems has it, all of our 4.5 systems do. Is this a bug of the ISO image, or a deliberate change? Thanks, Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
source address based routing
Hello, I was wondering if it is possible to do pure source address based routing under FreeBSD. What I really want to do is route packets from particular source addresses to tunnels (gif devices) regardless of what the packet's destination address is. thanks, matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
RE: source address based routing
inline.. > -Original Message- > From: Lars Eggert [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, June 26, 2002 5:10 PM > To: Matt Impett > Cc: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' > Subject: Re: source address based routing > > > Matt Impett wrote: > > I have looked at the firewall rather exetensively, but I > don't know that it > > can do what I want. > > Maybe you should describe what you want in a little more > detail then :-) gladly.. I am trying to implement reverse tunneling for mobile-IP. The basic idea is that packets must be reverse tunneled to different IP addresses depending on the source address of the packet. The reason the tunnel does not have an IP address associated with it is that I don't want to forward traffic down the tunnel for any other reason besides source addresses. As soon as I assign the tunnel interface an address, traffic sent to that address will be tunneled. > > > From what I can tell, the firewall fwd functionality allows > you to redirect > > a packet to a different next hop based on any of the > firewall matching rules > > (one of which is source address). > > > > What I want to do, however, is redirect the packet to a > tunnel (gif device) > > that has no next-hop associated with it. Is there any way > to do this?? > > How does it not have a next hop associated with it? Are you > leaving the > addresses unconfigured? Maybe you can still use ipfw like this: > > route add DUMMY_NEXT_HOP -interface GIF > ipfw add fwd DUMMY_NEXT_HOP all from SOURCE to any I have thought about doing this, but am a little concerned about assigning DUMMY_NEXT_HOP. As soon as I issue "route add DUMMY_NEXT_HOP -interface GIF", that DUMMY_NEXT_HOP address is now unusable by anyone else. Therefore, I guess it would have to be private, but then this would stop anyone from actually using this private address in the local domain. Plus, I don't know how many DUMMY_NEXT_HOPs to allocate, as I would need one for each tunnel I have set up, and the number of tunnels I set up is dependent on the number of mobile's that come into the system (which is somewhat of an unknown). What do you think?? matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
RE: source address based routing
I have looked at the firewall rather exetensively, but I don't know that it can do what I want. >From what I can tell, the firewall fwd functionality allows you to redirect a packet to a different next hop based on any of the firewall matching rules (one of which is source address). What I want to do, however, is redirect the packet to a tunnel (gif device) that has no next-hop associated with it. Is there any way to do this?? thanks, matt > -Original Message- > From: Lars Eggert [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, June 26, 2002 4:41 PM > To: Matt Impett > Cc: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' > Subject: Re: source address based routing > > > Matt Impett wrote: > > I was wondering if it is possible to do pure source address > based routing > > under FreeBSD. What I really want to do is route packets > from particular > > source addresses to tunnels (gif devices) regardless of > what the packet's > > destination address is. > > Firewall forwarding will do that, see ipfw (8), esp. the fwd action. > > Lars > -- > Lars Eggert <[EMAIL PROTECTED]> USC Information > Sciences Institute > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
RE: source address based routing
Ok.. Modifying the ipfw stuff is where I ended up after looking at this for a while. I have thought about adding something like the following: ipfw add fwd-intf GIF-DEVICE all from SOURCE to any The only problem I have seen with this (besides needing to modify the kernel and the user space ipfw application) was this: Once this rule is matched, the output routine of the GIF-DEVICE will be called and it will expect a rtentry structure to be passed. Unfortunately, I won't really have a correct rtentry structure as I am now forwarding to the device on a firewall rule instead of a routing table entry. However, from looking at the gif code, I don't think it really uses the rtentry structure anyway, so hopefully I won't break too much by passing a bogus one. Sound reasonable?? matt > -Original Message- > From: Lars Eggert [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, June 26, 2002 5:31 PM > To: Matt Impett > Cc: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' > Subject: Re: source address based routing > > > Matt Impett wrote: > > gladly.. I am trying to implement reverse tunneling for > mobile-IP. The > > basic idea is that packets must be reverse tunneled to different IP > > addresses depending on the source address of the packet. > The reason the > > tunnel does not have an IP address associated with it is > that I don't want > > to forward traffic down the tunnel for any other reason > besides source > > addresses. As soon as I assign the tunnel interface an > address, traffic > > sent to that address will be tunneled. > > Thanks, that was really helpful to get an idea of what your > scenario is! > > >>route add DUMMY_NEXT_HOP -interface GIF > >>ipfw add fwd DUMMY_NEXT_HOP all from SOURCE to any > > > > > > I have thought about doing this, but am a little concerned > about assigning > > DUMMY_NEXT_HOP. As soon as I issue "route add > DUMMY_NEXT_HOP -interface > > GIF", that DUMMY_NEXT_HOP address is now unusable by anyone else. > > Therefore, I guess it would have to be private, but then > this would stop > > anyone from actually using this private address in the local domain. > > Well, nobody should be using a private address in any domain that's > connected to the Internet, so you may be safe there. > > If not, then you could do either > > (1) modify ipfw to allow specification of a local interface (as > opposed to a gatway IP adress) in the fwd rule > or > (2) buy a large enough IP block so you can use your own > addresses for DUMMY_NEXT_HOP > > > Plus, > > I don't know how many DUMMY_NEXT_HOPs to allocate, as I > would need one for > > each tunnel I have set up, and the number of tunnels I set > up is dependent > > on the number of mobile's that come into the system (which > is somewhat of an > > unknown). > > This makes (2) look infeasible, but (1) may still be an option. > > Lars > -- > Lars Eggert <[EMAIL PROTECTED]> USC Information > Sciences Institute > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: source address based routing
Matt Impett wrote: > > Hello, > > I was wondering if it is possible to do pure source address based routing > under FreeBSD. What I really want to do is route packets from particular > source addresses to tunnels (gif devices) regardless of what the packet's > destination address is. Not yet there. We're working on it and much more. It'll (hopefully) be in 5.0-RELEASE in November. For a workaround at the moment have a look at the "fwd" action in ipfw. -- Andre To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: source address based routing
That's simple, FreeBSD can do policy based routing with ipfw. you need to compile a kernel with: options IPFIREWALL options IPFIREWALL_FORWARD myself I prefer to have these too but they're not absolutely necessary: options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=100 options IPFIREWALL_DEFAULT_TO_ACCEPT options IPDIVERT options DUMMYNET options BRIDGE Once we have a running kernel with the proper options, sysctl net.inet.ip.sourceroute=1 and use the ipfw fwd rules to set gateways based on policies. example: ipfw add fwd 192.168.1.1 ip from 172.20.0.0/24 to not 172.20.0.0/24 out makes 192.168.1.1 the next hop for any packet originating from 172.22.0.0/24 but destined outside 172.20.0.0/24 Baldur PS: man 8 ipfw and read http://www.freebsd.org/handbook and search http://www.google.com for further clues. On Wednesday 26 June 2002 20:30, you wrote: > Hello, > > I was wondering if it is possible to do pure source address based routing > under FreeBSD. What I really want to do is route packets from particular > source addresses to tunnels (gif devices) regardless of what the packet's > destination address is. > > thanks, > matt > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: source address based routing
Matt Impett wrote: > Ok.. Modifying the ipfw stuff is where I ended up after looking at this for > a while. I have thought about adding something like the following: > > ipfw add fwd-intf GIF-DEVICE all from SOURCE to any > > The only problem I have seen with this (besides needing to modify the kernel > and the user space ipfw application) was this: Once this rule is matched, > the output routine of the GIF-DEVICE will be called and it will expect a > rtentry structure to be passed. Unfortunately, I won't really have a > correct rtentry structure as I am now forwarding to the device on a firewall > rule instead of a routing table entry. > > However, from looking at the gif code, I don't think it really uses the > rtentry structure anyway, so hopefully I won't break too much by passing a > bogus one. > > Sound reasonable?? Yup, but I'm really too familiar with the routing or ipfw parts of the network stack. Ping Luigi? Lars PS: Minor nit: I'd overload the "fwd" action instead of creating a new one. -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: source address based routing
Matt Impett wrote: > I was wondering if it is possible to do pure source address based routing > under FreeBSD. What I really want to do is route packets from particular > source addresses to tunnels (gif devices) regardless of what the packet's > destination address is. Firewall forwarding will do that, see ipfw (8), esp. the fwd action. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: source address based routing
Matt Impett wrote: > I have looked at the firewall rather exetensively, but I don't know that it > can do what I want. Maybe you should describe what you want in a little more detail then :-) > From what I can tell, the firewall fwd functionality allows you to redirect > a packet to a different next hop based on any of the firewall matching rules > (one of which is source address). > > What I want to do, however, is redirect the packet to a tunnel (gif device) > that has no next-hop associated with it. Is there any way to do this?? How does it not have a next hop associated with it? Are you leaving the addresses unconfigured? Maybe you can still use ipfw like this: route add DUMMY_NEXT_HOP -interface GIF ipfw add fwd DUMMY_NEXT_HOP all from SOURCE to any Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: source address based routing
Matt Impett wrote: > gladly.. I am trying to implement reverse tunneling for mobile-IP. The > basic idea is that packets must be reverse tunneled to different IP > addresses depending on the source address of the packet. The reason the > tunnel does not have an IP address associated with it is that I don't want > to forward traffic down the tunnel for any other reason besides source > addresses. As soon as I assign the tunnel interface an address, traffic > sent to that address will be tunneled. Thanks, that was really helpful to get an idea of what your scenario is! >> route add DUMMY_NEXT_HOP -interface GIF >> ipfw add fwd DUMMY_NEXT_HOP all from SOURCE to any > > > I have thought about doing this, but am a little concerned about assigning > DUMMY_NEXT_HOP. As soon as I issue "route add DUMMY_NEXT_HOP -interface > GIF", that DUMMY_NEXT_HOP address is now unusable by anyone else. > Therefore, I guess it would have to be private, but then this would stop > anyone from actually using this private address in the local domain. Well, nobody should be using a private address in any domain that's connected to the Internet, so you may be safe there. If not, then you could do either (1) modify ipfw to allow specification of a local interface (as opposed to a gatway IP adress) in the fwd rule or (2) buy a large enough IP block so you can use your own addresses for DUMMY_NEXT_HOP > Plus, > I don't know how many DUMMY_NEXT_HOPs to allocate, as I would need one for > each tunnel I have set up, and the number of tunnels I set up is dependent > on the number of mobile's that come into the system (which is somewhat of an > unknown). This makes (2) look infeasible, but (1) may still be an option. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: source address based routing
This should almost be an FAQ... use ipfw and the FIREWALL_FORWARD option (ipfw fwd) to over-ride next hop routing decisions.. On Wed, 26 Jun 2002, Matt Impett wrote: > Hello, > > I was wondering if it is possible to do pure source address based routing > under FreeBSD. What I really want to do is route packets from particular > source addresses to tunnels (gif devices) regardless of what the packet's > destination address is. > > thanks, > matt > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Forwarding UDP packets
Try use mpd
it does proxy arp and handles some broadcast features I believe.
On Wed, 26 Jun 2002, Anthony Volodkin wrote:
> I use poptop+the pppd that is included with 4.6-RELEASE. On the XP
> side, my friend just sets up a "Virtual Private Networking Connection"
> using the native XP client.
>
> Here are my /etc/ppp/options, if you wanted protocol info:
> lock
> debug
> auth
> proxyarp
> +chap
> +chapms
> +chapms-v2
>
> and the relevant portion of ppp.conf:
> pptp:
> enable chap
> enable proxy
> set ifaddr 192.168.1.100 192.168.2.200-192.168.2.205 255.255.255.0
>
> >what method of doing pptp are you using?
> >
> >
> >On Wed, 26 Jun 2002, Anthony Volodkin wrote:
> >
> >
> >
> >>Hi,
> >>
> >>Recently I've been faced with an odd problem. I setup a pptp link to my
> >>network from my friend's XP machine. While the link functions fine
> >>(both ends can ping each other, etc), there is one problem with it. I
> >>cannot get any broadcast packets through the link. I receive them on
> >>the tun0 interface, but no matter what I try i can't get them out of the
> >>fxp0 interface. I cannot get them to go the other way either. I know
> >>this is against standards, as they suggest routers should not forward
> >>broadcast packets, but I would still like to have this ability.
> >>
> >>Did anyone ever write a patch of some sort or maybe found a tool that
> >>does this type of thing?
> >>(many people suggested natd, and after playing with that i was able to
> >>redirect some bcast packets from tun0 to 1 host on my lan. I was not
> >>able to do that in the other direction, however.)
> >>
> >>I've found an old post on the hackers list by Jonathan Chen that
> >>included a patch to enable this kind of functionality. I applied it to
> >>my 4.6-RELEASE kernel and it didn't do anything but add a sysctl
> >>variable. Any help would be greatly appreciated.
> >>
> >>Here is that post:
> >>
> >>---
> >>
> >>On FreeBSD -CURRENT and -STABLE, packets to broadcast addresses are not
> >>forwarded. For instance, if I have a FreeBSD router with interfaces
> >>192.168.1.1 and 192.168.2.1, and I send packets from 192.168.1.2 to
> >>192.168.2.255, the packets are dropped to the floor. IMO, this is wrong...
> >>but I haven't consulted all the RFC's so I'm not sure if some standard out
> >>there calls for it. In any case, the following patch creates a sysctl knob
> >>to turn on or off this feature (since it can be considered a security risk
> >>by some). I just want to ask around in case I turned out to be doing
> >>something incredibly evil. Comments?
> >>
> >>-Jon
> >>
> >>Index: in.h
> >>===
> >>RCS file: /export/ncvs/src/sys/netinet/in.h,v
> >>retrieving revision 1.55
> >>diff -u -r1.55 in.h
> >>--- in.h 2001/06/15 00:37:27 1.55
> >>+++ in.h 2001/08/09 15:12:19
> >>@@ -452,7 +452,8 @@
> >> #define IPCTL_FASTFORWARDING 14 /* use fast IP forwarding code */
> >> #define IPCTL_KEEPFAITH 15 /* FAITH IPv4->IPv6 translater ctl */
> >> #define IPCTL_GIF_TTL 16 /* default TTL for gif encap packet */
> >>-#define IPCTL_MAXID 17
> >>+#define IPCTL_FORWARD_BROADCAST 18 /* forward broadcast packets */
> >>+#define IPCTL_MAXID 18
> >>
> >> #define IPCTL_NAMES { \
> >> { 0, 0 }, \
> >>Index: ip_input.c
> >>===
> >>RCS file: /export/ncvs/src/sys/netinet/ip_input.c,v
> >>retrieving revision 1.174
> >>diff -u -r1.174 ip_input.c
> >>--- ip_input.c 2001/06/23 17:17:58 1.174
> >>+++ ip_input.c 2001/08/09 15:33:59
> >>@@ -103,6 +103,10 @@
> >> SYSCTL_INT(_net_inet_ip, IPCTL_FORWARDING, forwarding, CTLFLAG_RW,
> >> &ipforwarding, 0, "Enable IP forwarding between interfaces");
> >>
> >>+int ipforward_broadcast = 0;
> >>+SYSCTL_INT(_net_inet_ip, IPCTL_FORWARD_BROADCAST, forward_broadcast,
> >>CTLFLAG_RW,
> >>+&ipforward_broadcast, 0, "Enable broadcast packets when forwarding
> >>IP packets");
> >>+
> >> static int ipsendredirects = 1; /* XXX */
> >> SYSCTL_INT(_net_inet_ip, IPCTL_SENDREDIRECTS, redirect, CTLFLAG_RW,
> >> &ipsendredirects, 0, "Enable sending IP redirects");
> >>@@ -1684,7 +1688,8 @@
> >> }
> >>
> >> error = ip_output(m, (struct mbuf *)0, &ipforward_rt,
> >>- IP_FORWARDING, 0);
> >>+ IP_FORWARDING|
> >>+ (ipforward_broadcast?IP_ALLOWBROADCAST:0), 0);
> >> if (error)
> >>ipstat.ips_cantforward++;
> >> else {
> >>
> >>
> >>--
> >>Anthony Volodkin
> >>
> >>
> >>To Unsubscribe: send mail to [EMAIL PROTECTED]
> >>with "unsubscribe freebsd-net" in the body of the message
> >>
> >>
> >>
> >
> >
> >
>
>
>
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: source address based routing
On Wed, 26 Jun 2002, Lars Eggert wrote: > Matt Impett wrote: > > gladly.. I am trying to implement reverse tunneling for mobile-IP. The > > basic idea is that packets must be reverse tunneled to different IP > > addresses depending on the source address of the packet. The reason the > > tunnel does not have an IP address associated with it is that I don't want > > to forward traffic down the tunnel for any other reason besides source > > addresses. As soon as I assign the tunnel interface an address, traffic > > sent to that address will be tunneled. Surely 10.200.x.x is unlikely to be used.. it gives you 64000 possible tunnels. What I am having trouble with is that the tunnel to use depends on the SOURCE? That seems a little unusual.. Obviously I'm missing something in the words "reverse tunnelling". > > Thanks, that was really helpful to get an idea of what your scenario is! > > >>route add DUMMY_NEXT_HOP -interface GIF > >>ipfw add fwd DUMMY_NEXT_HOP all from SOURCE to any > > > > > > I have thought about doing this, but am a little concerned about assigning > > DUMMY_NEXT_HOP. As soon as I issue "route add DUMMY_NEXT_HOP -interface > > GIF", that DUMMY_NEXT_HOP address is now unusable by anyone else. > > Therefore, I guess it would have to be private, but then this would stop > > anyone from actually using this private address in the local domain. ability to forward to an interface would be kind of cool.. > > Well, nobody should be using a private address in any domain that's > connected to the Internet, so you may be safe there. > > If not, then you could do either > > (1) modify ipfw to allow specification of a local interface (as > opposed to a gateway IP adress) in the fwd rule this would be cool but I'm not sure how feasible.. I have not looked at Luigi's new ipfw implementation yet. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: SOLVED! Native PPPoE broken (4.6-STABLE), RP-PPPoE working?!
Just to close off this issue an feed it to the archives in case anyone else runs into this issue, the telco found the article below in the vendor's knowledge database. Again to summarize, if you use FreeBSD, PPPoE and your ISP or your ISP's telco uses an ERX as the PPPoE concentrator, make sure you disable and prevent VJ header compression as it will not work. Bell Canada has been slowly deploying these boxes so if you use Sympatico, or your ISP is in Quebec or Ontario, you will start to run into this issue as the telco slow gets rid of their Redback SMSes and replaces them with Unisphere's ERX boxes. The solution I found was to make sure that its also disabled and not offered in RADIUS either, so you might have to talk to your ISP if they have it configured, as we did. ---Mike *** Knowledge Database - Search Results Knowledge Asset ID#: 1773.0 Subject: The ERX does not support IP header compression as described in RFC 2507 and RFC 2508. Type: SW Release: SW Version: Problem Description: The ERX does not support and does not yet have plans to support IP header compression. For a full description of IP header compression refer to RFC 2507 and RFC 2508. It basically says that multiple packets to and from the same destinations can get their headers compressed to save about 8 bytes per packet. This feature has been requested in case 10349 Workaround: Solution: On Tue, 25 Jun 2002 11:40:48 -0400, in sentex.lists.freebsd.net you wrote: > >In short, VJ-Header Compression! Why, I dont know. The exact same config >works agains the SMSes by Redback. But not the Unisphere ERX > >Here is what I did to get it to all work. > >a) On my radius server, I had to get rid of > Framed-Compression = Van-Jacobsen-TCP-IP >b) On the FreeBSD box, I had to put > disable vjcomp > > >_Before_, on the Cisco terminating L2TP server we see > >bell-border#show int vi426 >Virtual-Access426 is up, line protocol is up > Hardware is Virtual Access interface > Interface is unnumbered. Using address of Loopback0 (64.7.134.129) > MTU 1492 bytes, BW 18868 Kbit, DLY 10 usec, > reliability 255/255, txload 1/255, rxload 1/255 > Encapsulation PPP, loopback not set > Keepalive set (10 sec) > DTR is pulsed for 5 seconds on reset > LCP Open > Open: IPCP > Last input 01:11:57, output never, output hang never > Last clearing of "show interface" counters 03:33:26 > Queueing strategy: fifo > Output queue 0/40, 0 drops; input queue 0/75, 0 drops > 5 minute input rate 0 bits/sec, 0 packets/sec > 5 minute output rate 0 bits/sec, 0 packets/sec > 9265 packets input, 4481181 bytes, 0 no buffer > Received 0 broadcasts, 0 runts, 0 giants, 0 throttles > 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort > 8720 packets output, 1141908 bytes, 0 underruns > 0 output errors, 0 collisions, 0 interface resets > 0 output buffer failures, 0 output buffers swapped out > 0 carrier transitions >bell-border#show int vi426 confi >Virtual-Access426 is an L2TP link interface > >Building configuration... > >interface Virtual-Access426 configuration... >mtu 1492 >ip unnumbered Loopback0 >ip tcp header-compression > >And _after_ > >bell-border#show int vi63 >Virtual-Access63 is up, line protocol is up > Hardware is Virtual Access interface > Interface is unnumbered. Using address of Loopback0 (64.7.134.129) > MTU 1492 bytes, BW 18868 Kbit, DLY 10 usec, > reliability 255/255, txload 1/255, rxload 1/255 > Encapsulation PPP, loopback not set > Keepalive set (10 sec) > DTR is pulsed for 5 seconds on reset > LCP Open > Open: IPCP > Last input 00:00:09, output never, output hang never > Last clearing of "show interface" counters 00:14:45 > Queueing strategy: fifo > Output queue 0/40, 0 drops; input queue 0/75, 0 drops > 5 minute input rate 0 bits/sec, 0 packets/sec > 5 minute output rate 0 bits/sec, 0 packets/sec > 10 packets input, 217 bytes, 0 no buffer > Received 0 broadcasts, 0 runts, 0 giants, 0 throttles > 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort > 8 packets output, 139 bytes, 0 underruns > 0 output errors, 0 collisions, 0 interface resets > 0 output buffer failures, 0 output buffers swapped out > 0 carrier transitions >bell-border#show int vi63 config >Virtual-Access63 is an L2TP link interface > >Building configuration... > >interface Virtual-Access63 configuration... >mtu 1492 >ip unnumbered Loopback0 > > >iscar# ifconfig tun0 >tun0: flags=8051 mtu 1492 > inet6 fe80::2d0:b7ff:fea6:4285%tun0 prefixlen 64 scopeid 0x8 > inet 64.7.134.131 --> 64.7.134.129 netmask 0xff00 > Opened by PID 55 >iscar# > >fetch ftp://ftp.isc.org/isc/bind9/9.2.1/bind-9.2.1.tar.gz >Receiving bind-9.2.1.tar.gz (5021044 b
