Re: Restricting traffic on one interface
Thanks for the suggestion, but where do I get ipf? I don't see it in the FreeBSD packages region under networking or security. The closest I see in functionality I see is xinetd, but it only seems to allow me to specity ip addresses to enable/disable, but does not seem to have an option to specify the network interface. I guess xinetd is better than nothing, if I trust the outer firewall to filter out unexpected incoming ip addresses, but the whole point is that I do NOT trust the outer firewall to do it's job perfectly. Regards, orville. On Sun, 20 May 2001, Chojin wrote: > Use ipf > (it's not ipfw) > - Original Message - > From: "Orville R. Weyrich.Jr" <[EMAIL PROTECTED]> > Cc: "Freebsd Net (E-mail)" <[EMAIL PROTECTED]> > Sent: Sunday, May 20, 2001 8:07 AM > Subject: Restricting traffic on one interface > > > > Hi -- > > > > I have a dual homed FreeBSD-4.3 machine and want to restrict traffic on > > one interface but not the other (one interface is to a trusted network and > > the other is not). > > > > What I want is the untrusted interface to only present SMTP and HTTP > > ports, while the trusted interface presents telnet, ftp, NFS, SMB, etc. > > > > What is the best way to do this? The machine does NOT have IP forwarding > > enabled. > > > > --- > > Orville R. Weyrich, Jr. Weyrich Computer Consulting > > mailto:[EMAIL PROTECTED] KD7HJVhttp://www.weyrich.com > > --- > > > > > > 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 > === IF YOU WANT REFORM VOTE REFORM --- Orville R. Weyrich, Jr. Weyrich Computer Consulting mailto:[EMAIL PROTECTED] KD7HJVhttp://www.weyrich.com --- Visit our online collection of book reviews: http://www.weyrich.com/book_reviews/ Ask about our world wide web services! --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Restricting traffic on one interface
> Thanks for the suggestion, but where do I get ipf? I don't see it in the it is part of the base system. BTW both ipfilter and ipfw seem to do the job you want, so recommending the use of one instead of the other is as technically sound as saying to disconnect the network cable on the internal side (which is the most secure thing you can do provided you do not have a wireless card on the motherboard... these days you cannot trust anything anymore!) cheers luigi > FreeBSD packages region under networking or security. The closest I see > in functionality I see is xinetd, but it only seems to allow me to specity > ip addresses to enable/disable, but does not seem to have an option to > specify the network interface. > > I guess xinetd is better than nothing, if I trust the outer firewall to > filter out unexpected incoming ip addresses, but the whole point is that I > do NOT trust the outer firewall to do it's job perfectly. > > Regards, > > orville. > > On Sun, 20 May 2001, Chojin wrote: > > > Use ipf > > (it's not ipfw) > > - Original Message - > > From: "Orville R. Weyrich.Jr" <[EMAIL PROTECTED]> > > Cc: "Freebsd Net (E-mail)" <[EMAIL PROTECTED]> > > Sent: Sunday, May 20, 2001 8:07 AM > > Subject: Restricting traffic on one interface > > > > > > > Hi -- > > > > > > I have a dual homed FreeBSD-4.3 machine and want to restrict traffic on > > > one interface but not the other (one interface is to a trusted network and > > > the other is not). > > > > > > What I want is the untrusted interface to only present SMTP and HTTP > > > ports, while the trusted interface presents telnet, ftp, NFS, SMB, etc. > > > > > > What is the best way to do this? The machine does NOT have IP forwarding > > > enabled. > > > > > > --- > > > Orville R. Weyrich, Jr. Weyrich Computer Consulting > > > mailto:[EMAIL PROTECTED] KD7HJVhttp://www.weyrich.com > > > --- > > > > > > > > > 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 > > > > === > IF YOU WANT REFORM VOTE REFORM > --- > Orville R. Weyrich, Jr. Weyrich Computer Consulting > mailto:[EMAIL PROTECTED] KD7HJVhttp://www.weyrich.com > --- > Visit our online collection of book reviews: > > http://www.weyrich.com/book_reviews/ > > Ask about our world wide web services! > --- > > > 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
Multiple IP addresses on the same host
Hi, We have an ethernet host & many pseudo ethernet interfaces configured. Suppose I send a packet to pseudo ethernet interface. The reply from pseudo ethernet interface is sent through the physical interface. This response, has the IP address of the physical interface instead of the IP address of Pseudo Ethernet Interface. So, the host which sent a packet to pseudo ethernet interface, is discarding this packet because of the IP address. Can anybody tell me why this is happening & suggest some way to correct it? I guess this is happening because we bind the socket to INADDR_ANY. Is that right??? Thanks, Suma To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
L2TP and FreeBSD - is it possible?
Hello, FreeBSD community! Firstly, excuse my English! ;-) DESCRIPTION: I have Win2000 server in private network (IP = 192.168.1.1) and FreeBSD box with two netcards (one of them plugged to 192.168.1/24 network, another - in ISP's LAN). On FreeBSD i have "closed"-style firewall and some services (primary DNS, proxy & mail). I have not and even don't plan to install NAT on this box. Now, i want to grant access for our remote users to Win2000 server in internal network through L2TP+IPSec. Latter part doesn't bother me, but former... So, i need a good advice from guru: a) Is L2TP supported by FreeBSD? b) Which way is more "right" - to install L2TP server on Win2000 and divert all VPN traffic to it, or configure FreeBSD box as L2TP server? c) Is there any resources about "L2TP & FreeBSD" (i know, it should be first question)? Please, cc: to my e-mail, 'cos i have not enough time to looking through all freebsd's maillists. Thanks in advance! -- WBR, Alex Markov. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Using connect() on UDP RPC client sockets.
In message <[EMAIL PROTECTED]>, Barney Wolff writes: >1. Multi-homed hosts are in fact very common, especially in >corporate environments. To get the right source addr in >its reply, the server must open separate sockets on each >of its host's addresses - as named and ntpd do. And then >it has to detect changes in the set of addresses. Hard >work for not a lot of gain. An alternative to this approach on the server side, which has been discussed before, is a mechanism to set the source address of individual outgoing UDP datagrams. There is already the IP_RECVDSTADDR socket option which can be used to determine the source address of the incoming packet: If the IP_RECVDSTADDR option is enabled on a SOCK_DGRAM socket, the recvmsg(2) call will return the destination IP address for a UDP datagram. The msg_control field in the msghdr structure points to a buffer that contains a cmsghdr structure followed by the IP address. The cmsghdr fields have the following values: cmsg_len = sizeof(struct in_addr) cmsg_level = IPPROTO_IP cmsg_type = IP_RECVDSTADDR If an IP_SENDSRCADDR control message was implemented, servers could use it to reply from the address to which the request was sent. This would not require opening additional sockets, and it would not need to detect interface address changes. Another alternative would be to make IP_HDRINCL work with UDP sockets, so that the server could construct a UDP header at the start of the datagram containing the required source address. I would prefer to see the server-side issue being fixed so that the clients can use the simple, secure approach. Then for interoperating with `broken' servers, there needs to be a way to revert to the old client behaviour. >2. Source addr is so easy to spoof that it adds nothing to security. True, but internal networks can be trivially protected from spoofed packets coming in from less secure networks, and this is one of the most basic levels of filtering employed by most firewalls. Also, local unpriviledged accounts on unix servers cannot be used to spoof source addresses. However in both of these cases, it may still be possible to get a bogus reply accepted by an RPC client. Incoming packets do not need to spoof any addresses - they just require that the firewall lets in packets to UDP ports (i.e. many stateless firewalls). Local unpriviledged users can also send bogus replies simply by opening a UDP socket and sending a datagram to the RPC client port. It is this behaviour that I think is undesirable, and may be surprising to many people. Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Using connect() on UDP RPC client sockets.
On Mon, 2001/05/21 at 14:43:09 +0100, Ian Dowse wrote: > In message <[EMAIL PROTECTED]>, Barney Wolff writes: > >1. Multi-homed hosts are in fact very common, especially in > >corporate environments. To get the right source addr in > >its reply, the server must open separate sockets on each > >of its host's addresses - as named and ntpd do. And then > >it has to detect changes in the set of addresses. Hard > >work for not a lot of gain. > > An alternative to this approach on the server side, which has been > discussed before, is a mechanism to set the source address of > individual outgoing UDP datagrams. There is already the IP_RECVDSTADDR > socket option which can be used to determine the source address of > the incoming packet: > > If the IP_RECVDSTADDR option is enabled on a SOCK_DGRAM > socket, the recvmsg(2) call will return the destination IP > address for a UDP datagram. The msg_control field in the > msghdr structure points to a buffer that contains a cmsghdr > structure followed by the IP address. The cmsghdr fields > have the following values: > > cmsg_len = sizeof(struct in_addr) > cmsg_level = IPPROTO_IP > cmsg_type = IP_RECVDSTADDR > > If an IP_SENDSRCADDR control message was implemented, servers could > use it to reply from the address to which the request was sent. > This would not require opening additional sockets, and it would > not need to detect interface address changes. I have a patch that does just that (although it just overloads IP_RECVDSTADDR for sendmsg instead of creating a new flag). I wrote it some time ago for a DNS server (the standard requires the source address to be the address the packet went to). It may need some resynching, but if you want, I can dig it out and prepare it for committing. I anyway wanted to do this some time... - thomas To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Using connect() on UDP RPC client sockets.
In message <[EMAIL PROTECTED]>, Thomas Moestl writes:
>
>I have a patch that does just that (although it just overloads
>IP_RECVDSTADDR for sendmsg instead of creating a new flag). I wrote it
>some time ago for a DNS server (the standard requires the source
>address to be the address the packet went to). It may need some
>resynching, but if you want, I can dig it out and prepare it for
>committing. I anyway wanted to do this some time...
Thanks! I know I had seen this somewhere - turns out I had saved
it in my freebsd-net mailbox too. Getting this functionality
committed would be a great first step towards resolving the wrong-
address issue at least between FreeBSD hosts.
I think the option should be renamed to something like IP_SENDSRCADDR
just to avoid confusion - does this seem reasonable? I'll read
through the patch shortly and maybe see if it still applies.
Actually, a bit more searching has shown up some more posibilities.
IPv6 uses a IPV6_PKTINFO option, based on the in6_pktinfo struct:
struct in6_pktinfo {
struct in6_addr ipi6_addr; /* src/dst IPv6 address */
unsigned intipi6_ifindex; /* send/recv interface index */
};
and it seems Linux has something similar for IPv4 which uses an
IP_PKTINFO option:
struct in_pktinfo
{
unsigned int ipi_ifindex; /* Interface index */
struct in_addr ipi_spec_dst;/* Routing destination address */
struct in_addr ipi_addr; /* Header Destination address */
};
I think the idea of both is that you can specify the source address
and interface of outgoing packets, and get the destination address
and receive interface of incoming packets. I suppose the ipi_spec_dst
in the Linux in_pktinfo is to use a different destination address
for the routing table lookup; I'm not sure why you'd want to do
that though.
Would that seem a better interface to implement?
Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: Using connect() on UDP RPC client sockets.
< said: > I think the option should be renamed to something like IP_SENDSRCADDR > just to avoid confusion - does this seem reasonable? I think it's OK to add an additional name for the same control message, but it should be possible (and documented) to use the exact control message as was returned from recvmsg() as argument to sendmsg(). -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Using connect() on UDP RPC client sockets.
< said: > Where an RFC mandates that the reply source address must be the same > as the request dest addr This is true for *any* protocol built over IP, regardless of what the individual protocol specifications say. See RFC 1122 sections 3.3.4.2, 4.1.3.5, and 4.2.3.7. (It actually says ``SHOULD'' in the first two sections, which translates as ``you'd better have a damn good reason not to''.) -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Using connect() on UDP RPC client sockets.
Well there's SCTP ... I have a general comment/question: Is there a policy on when it is appropriate to create a FreeBSD-only feature? I can certainly see it when there is a big win to be had. A feature like this, though, if not likely to become part of Posix/Single-Unix or whatever the term is these days, is of questionable value. Can anyone realistically see bind or ntpd being modified to take advantage of it when running on FreeBSD? Use of such a feature buried in FreeBSD's own rpc code is different, I suppose. Barney Wolff On Mon, May 21, 2001 at 02:50:13PM -0400, Garrett Wollman wrote: > < said: > > > Where an RFC mandates that the reply source address must be the same > > as the request dest addr > > This is true for *any* protocol built over IP, regardless of what the > individual protocol specifications say. See RFC 1122 sections > 3.3.4.2, 4.1.3.5, and 4.2.3.7. (It actually says ``SHOULD'' in the > first two sections, which translates as ``you'd better have a damn > good reason not to''.) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: DUMMYNET and IPv6
> On Sat, 12 May 2001 15:26:08 +0200 (CEST), > David Delibasic <[EMAIL PROTECTED]> said: > Hellow > Will IPv6 start supporting DUMMYNET and when ??? Sorry for the non-informative response, but I think it would still be better than ignorance... We, the KAME project, do not have any plans to implement it at this moment (acutally we have severe lack of human resourse for supporting FreeBSD IPv6 stuff...). If someone else tries it, it would be welcome very much. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
interface flags
Hi, i have freebsd 4.2 stable. what is difference between interface flags IFF_UP and IFF_RUNNING? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
