Re: ipf ftp proxy problem?
On Wed, 2003-02-19 at 21:26, Shane Hickey wrote: > On Tue, 2003-02-18 at 15:10, Marco Radzinschi wrote: > > Place the following BEFORE any other rules, and replace $intsubnet with > > your internal subnet. The second rule will allow active FTP from the > > firewall itself. > > > > map dc0 $intsubnet -> 1.1.1.1/32 proxy port ftp ftp/tcp > > map dc0 1.1.1.1/32 -> 1.1.1.1/32 proxy port ftp ftp/tcp > > Hmm... I had never tried to ftp from the actual firewall box. I just > added the second rule and I am now able to do active ftp from the > firewall box, but not from any of the internal boxes. I'm sending ipmon > data to syslog and I can't see hide nor hair of anything in the logs > pertaining to these failed active sessions. Hooo ah! I figured it out. A tcpdump showed me that my ftp data wasn't matching the first two rules. That is, let's say my internal network is 10.0.0.0/24 and some particular hosts are 10.0.0.1 and 10.0.0.2. Let's then say that my outside interface's IP is 1.1.1.1. My outside interface also has 2 IP aliases of 2.2.2.2 and 3.3.3.3. These are my three static publicly routable IPs that I use for public services. Anyway, that said, here's the nat rules that I had in place. map dc0 10.0.0.0/24 -> 1.1.1.1/32 proxy port ftp ftp/tcp map dc0 1.1.1.1/32 -> 1.1.1.1/32 proxy port ftp ftp/tcp map dc0 10.0.0.0/24 -> 1.1.1.1/32 portmap tcp/udp auto map dc0 10.0.0.1/32 -> 2.2.2.2/32 map dc0 10.0.0.2/32 -> 3.3.3.3/32 map dc0 10.0.0.0/24 -> 1.1.1.1/32 I had assumed that the rules would be checked in order and then ipnat would exit with the first matching rule. What seems to have happened, though, is that the most specific rule is matched? When I ftp'd from 10.0.0.1, it was being mapped to 2.2.2.2 and not 1.1.1.1. Anyway, thanks much for all the help. I apologize if these were goofy questions. Shane To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: ipf ftp proxy problem?
On Tue, 2003-02-18 at 15:10, Marco Radzinschi wrote: > Place the following BEFORE any other rules, and replace $intsubnet with > your internal subnet. The second rule will allow active FTP from the > firewall itself. > > map dc0 $intsubnet -> 1.1.1.1/32 proxy port ftp ftp/tcp > map dc0 1.1.1.1/32 -> 1.1.1.1/32 proxy port ftp ftp/tcp Hmm... I had never tried to ftp from the actual firewall box. I just added the second rule and I am now able to do active ftp from the firewall box, but not from any of the internal boxes. I'm sending ipmon data to syslog and I can't see hide nor hair of anything in the logs pertaining to these failed active sessions. Does anyone have any idea of some troubleshooting steps I might take? Thanks, shane To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: ipf ftp proxy problem?
On 17 Feb 2003, Shane Hickey wrote: > Howdy all, > I have a freebsd firewall and I want to be able to do make both passive > and active ftp client connections from my inside network to the outside > world. I'm using ipf and ipnat compiled into the kernel. I followed > the IPF HOWTOs that I've read and I'm hitting a brick wall. > My outside interface is dc0 and let's say my outside IP is 1.1.1.1. > I've tried both of the following rules in my /etc/ipnat.rules file with > no success. > > map dc0 0/0 -> 1.1.1.1/32 proxy port 21 ftp/tcp > map dc0 0/0 -> 0/32 proxy port ftp ftp/tcp > > When I say no success, I mean that I am able to establish a remote ftp > connection, but when I do a 'ls' I get a > > 425 Can't build data connection: No route to host > > I'm sure I'm doing something foolish, so any advice would be greatly > appreciated. Oh yeah, I'm running FreeBSD5.0-release and IPF version > 3.4.29. > > Thanks in advance for any help. > > -- > Shane Hickey : Network/System Consultant > GPG KeyID: 777CBF3F > Key fingerprint: 254F B2AC 9939 C715 278C DA95 4109 9F69 777C BF3F > Listening to: MC5 - 12 I Can Only Give you Everyth Place the following BEFORE any other rules, and replace $intsubnet with your internal subnet. The second rule will allow active FTP from the firewall itself. map dc0 $intsubnet -> 1.1.1.1/32 proxy port ftp ftp/tcp map dc0 1.1.1.1/32 -> 1.1.1.1/32 proxy port ftp ftp/tcp Marco Radzinschi E-Mail: [EMAIL PROTECTED] Tue Feb 18 17:07:05 EST 2003 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: ipf ftp proxy problem?
On Monday, 17 February 2003 at 22:08:41 -0700, Shane Hickey wrote: > Howdy all, > I have a freebsd firewall and I want to be able to do make both passive > and active ftp client connections from my inside network to the outside > world. I'm using ipf and ipnat compiled into the kernel. I followed > the IPF HOWTOs that I've read and I'm hitting a brick wall. > My outside interface is dc0 and let's say my outside IP is 1.1.1.1. > I've tried both of the following rules in my /etc/ipnat.rules file with > no success. > > map dc0 0/0 -> 1.1.1.1/32 proxy port 21 ftp/tcp > map dc0 0/0 -> 0/32 proxy port ftp ftp/tcp > > When I say no success, I mean that I am able to establish a remote ftp > connection, but when I do a 'ls' I get a > > 425 Can't build data connection: No route to host > > I'm sure I'm doing something foolish, so any advice would be greatly > appreciated. Oh yeah, I'm running FreeBSD5.0-release and IPF version > 3.4.29. > My ipf.rules for passive FTP contains: pass in quick on rl0 proto tcp from any to any port = 21 flags S keep state keep frags pass in quick on rl0 proto tcp from any to any port > 1023 flags S keep state And ipnat.rules: map rl0 192.168.1.0/24 -> 0.0.0.0/32 proxy port ftp ftp/tcp Kjell > Thanks in advance for any help. > > -- > Shane Hickey : Network/System Consultant > GPG KeyID: 777CBF3F > Key fingerprint: 254F B2AC 9939 C715 278C DA95 4109 9F69 777C BF3F > Listening to: MC5 - 12 I Can Only Give you Everyth > > > 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
