Sending 'security run output' to another email address
Hi folks.. I've got FreeBSD 4.7 running as my router to the net from local systems. I am wanting the output from 'security run output' to be sent to my isp email address. The problem is that it's sending the mail to me but bouncing because it's sending from FBSD.npgcable.com which fails the dns lookup the isp uses. I tried masqerading as just npgcable.com and that sorta works.. I now get the bounced emails to this address.. I aliased root to admin account and admin account to my address here. Is there a way to tell it to NOT use From: [EMAIL PROTECTED] ? To just use From: [EMAIL PROTECTED] Or maybe another way all together to get it to mail me here on my local net from the router with out going through the ISP? I am useing the advice from the handbook http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mail.html which is only halfway working. Thanks for any further advice :) WillyB To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: different ipfw/natd prob
Here's what I did that worked for me on FreeBSD 4.5-RELEASE Maybe this will help you some. Kernel recompile options I added: options IPFIREWALL # I added for firewall options IPFIREWALL_DEFAULT_TO_ACCEPT# I added for firewall options IPFIREWALL_VERBOSE # I added for firewall options IPFIREWALL_VERBOSE_LIMIT=10 # I added for firewall options IPFIREWALL_DEFAULT_TO_ACCEPT# I added for firewall options IPFIREWALL_FORWARD # I added for firewall options IPDIVERT# I added for natd ipfw rules: /sbin/ipfw add 100 pass all from 127.0.0.1 to 127.0.0.1 /sbin/ipfw add 200 divert natd all from any to any via rl0 ifconfig: xl0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=3rxcsum,txcsum inet 192.168.0.1 netmask 0xff00 broadcast 192.168.0.255 inet6 fe80::201:2ff:fee8:2298%xl0 prefixlen 64 scopeid 0x1 ether 00:01:02:e8:22:98 media: Ethernet autoselect (100baseTX full-duplex) status: active rl0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 24.xx.xxx.61 netmask 0xfe00 broadcast 24..xxx.255 inet6 fe80::250:bfff:fe51:5503%rl0 prefixlen 64 scopeid 0x2 ether 00:50:bf:51:55:03 media: Ethernet autoselect (100baseTX full-duplex) status: active rc.conf: gateway_enable=YES firewall_enable=YES firewall_type=OPEN natd_enable=YES natd_interface=rl0 natd_flags=-f /etc/natd.cf hostname=mygatewayhost ifconfig_rl0=inet 24.121.16.61 netmask 255.255.254.0 ifconfig_xl0=inet 192.168.0.1 netmask 255.255.255.0 WillyB [EMAIL PROTECTED] wrote: following is rc.conf, /etc/natd.conf, ifconfig, ipfw show rc.conf inetd_enable=YES kern_securelevel_enable=NO linux_enable=YES tcp_extensions=YES named_enable=YES sendmail_enable=NO portmap_enable=YES router_enable=yes router=/sbin/routed router_flags=-q defaultrouter=68.abc.de.1 hostname=www.kingrea.com network_interfaces=lo0 fxp0 dc0 ifconfig_lo0=inet 127.0.0.1 ifconfig_dc0=inet 68.abc.de.14 netmask 255.255.255.0 media 10baseT/UTP ifconfig_fxp0=inet 192.168.2.1 netmask 255.255.255.0 firewall_enable=YES firewall_type=OPEN gateway_enable=YES natd_enable=YES natd_interface=dc0 natd_flags=-f /etc/natd.conf natd.conf interface dc0 use_sockets yes same_ports yes ifconfig dc0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 68.abc.de.14 netmask 0xff00 broadcast 68.abc.de.255 inet6 fe80::204:5aff:fe5a:9987%dc0 prefixlen 64 scopeid 0x1 ether 00:04:5a:5a:99:87 media: Ethernet 10baseT/UTP status: active fxp0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 192.168.2.1 netmask 0xff00 broadcast 192.168.2.255 inet6 fe80::2a0:c9ff:fe5c:3738%fxp0 prefixlen 64 scopeid 0x2 ether 00:a0:c9:5c:37:38 media: Ethernet autoselect (100baseTX) status: active lp0: flags=8810POINTOPOINT,SIMPLEX,MULTICAST mtu 1500 faith0: flags=8002BROADCAST,MULTICAST mtu 1500 lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 inet 127.0.0.1 netmask 0xff00 ppp0: flags=8010POINTOPOINT,MULTICAST mtu 1500 sl0: flags=c010POINTOPOINT,LINK2,MULTICAST mtu 552 ipfw show 00100 0 0 allow ip from any to any via lo0 00200 0 0 deny ip from any to 127.0.0.0/8 00300 0 0 deny ip from 127.0.0.0/8 to any 65000 4208345040 all ip from any to any 65535 0 0 deny ip from any to any thanks for assistance! stephen d. kingrea On Fri, 17 Jan 2003, Bill Moran wrote: Stephen D. Kingrea wrote: i have a slightly different ipfw/natd problem. machines on the lan can ping internal nic on the server (fbsd 4.7), and the external nic, but can not ping or reach anything outside. unless i telnet into the server, then telnet out. currently running ipfw open until problem is solved. server can ping all machines on lan. On a wild guess, it sounds like your divert rule is wrong. Need more information to help with this. Please repost to the list and include the following: The output of 'ipfw show' The output of 'ifconfig' The contents of your rc.conf file -- Bill Moran Potential Technologies http://www.potentialtech.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message -- Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
natd port forwarding acting wierd
Hi I finally got natd and ipforwading set up but have a slight problem I don't understand. The IP forwarding works from the internet, through the cable modem and through the freeBSD router I set up for my internal network, to a www server on the private lan. I can't connect to my server however from my local net using the ip of the external net. I was asking some folks I know for help.. when they told me what the page had on it... so it was working for them on their systems from various places around the country.. but still gives me a connection refused when going from a local machine. I gave them the ip my ISP gives me.. and it worked.. I try the same IP and it doesn't work from my 192.168.0.* box, which by the way is the same box with the www server on it I am trying to connect to. ( I can connect to it using the local ip and machine name, but that's not the point ) ;) Does anyone have any ideas as to why this is happening? Thanks in advance. :) WillyB To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: natd port forwarding acting wierd
Thanks for your answer and solutions Matthew :)
This is my 4th day of using freeBSD and I'm still very new to it.
I have used RedHat prior to this and when I could not get it to connect
to my ISP via the cable modem I installed freeBSD. ;)
Actually.. I don't fully understand the rc.firewall script, so I made my
own very simple one :)
I will try to implement the reverse proxy solution you wrote about as
this will probably be easiest for me.
Thanks again for your help and very thorough explination. I understand
what's happening now ;)
Re's and Cheers!
WillyB
Matthew Seaman wrote:
On Thu, Jan 16, 2003 at 01:49:08AM -0700, WillyB wrote:
I finally got natd and ipforwading set up but have a slight problem I
don't understand.
The IP forwarding works from the internet, through the cable modem and
through the freeBSD router I set up for my internal network, to a www
server on the private lan.
I can't connect to my server however from my local net using the ip of
the external net.
If you're following the way natd is setup in /etc/rc.firewall, viz
this chunk of code:
case ${firewall_type} in
[Oo][Pp][Ee][Nn]|[Cc][Ll][Ii][Ee][Nn][Tt])
case ${natd_enable} in
[Yy][Ee][Ss])
if [ -n ${natd_interface} ]; then
${fwcmd} add 50 divert natd all from any to any via ${natd_interface}
fi
;;
esac
esac
notice that the rule to divert packets into natd only selects packets
that traverse the external interface (${natd_interface} in
/etc/rc.conf) of your gateway machine. Packets from your internal
(192.168.0.0/24) network will not pass through that interface even if
they are destined for your nat'ed address, so they won't hit the
divert rule and they won't get nat'ed.
Now, you might think that the obvious answer is just to drop the 'via
${natd_interface}' part of the divert rule, so that all packets
passing across your gateway machine pass through nat'ing.
Unfortunately, this will fail to work --- apart from the fact that it
will probably screw things up by trying to nat packets going via the
loopback interface and all sorts of other unintended consequences,
your original aim of being able to access your internal server as if
you were coming from outside your net still won't work.
What happens is this:
You send a packet to the NAT address on your gateway.
The modified firewall rules pass the packet through the divert socket
to natd, which rewrites the destination address to be that of your
internal server. Nb. the *source* address in the packet is left
untouched.
The packet is then sent across your internal network to your server.
The server deals with it as normal, and generates a response packet
back to the *original sender*, with it's own address as the source.
That happens to be to a machine on the local network, so the response
packet gets delivered straight there. Normally, the response packet
would be to a remote network and the packet would have to pass through
your gateway to get there, thus giving the natd machinery the chance
to process it, and replace the sender address with the nat address.
Now, the original machine is expecting to have a tcp conversation with
a machine using your nat address. Unfortunately the packets it
receives in response appear to come from some machine on your local
net. In order to preserve sanity it ignores those packets and keeps
listening out for the expected response from the place it sent the
packets to. Eventually it all times out and everybody gives up in
disgust.
There are two possible solutions to this problem.
i) Split Horizon. Usually implemented in terms of DNS, but you
can fudge the issue using /etc/hosts on your internal machines if
that's easier for you. All this does is arrange things so that a
lookup for www.mysite.com returns the address of the server on the
internal network when looked up from inside, and the address of
the nat gateway when looked up from outside.
ii) Reverse Proxy. Instead of accessing your internal server via
a NAT gateway, set up a web proxy on your gateway machine. Unlike
a normal web proxy, instead of grabbing web pages from out on the
net for the benefit of your internal systems, the reverse proxy
grabs web pages from your internal machine for the benefit of the
rest of the net. The NAT gateway will rewrite one out of the
sender or recipient addresses of any packets addressed to it,
whereas the proxy will effectively rewrite both the sender and
recipient addresses, solving the problem detailed above.
Cheers,
Matthew
--
Your favorite stores, helpful shopping tools and great gift ideas.
Experience the convenience of buying online with Shop@Netscape!
http://shopnow.netscape.com/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-questions in the body of the message
