What kind of firewall rules do you have the optional interface in question?
On 9/13/05, Matthew Lenz <[EMAIL PROTECTED]> wrote: > yes sir :) em2 .. the one mentioned in the block log entry in my > original post. > > --clip-- > > pf: 23. 996387 rule 254/0(match): block in on em2: WWW.WWW.WWW.WWW.44635 > 127.0.0.1.8021: S 3451987609:3451987609(0) win 5840 > <mss1460,sackOK,timestamp[|tcp]> > > WWW.WWW.WWW.WWW is the machine's private 'OPT2 net' ip from which I'm > trying to ftp to a public internet site. > > -------- > > On Tue, 2005-09-13 at 15:32 -0400, Scott Ullrich wrote: > > rdr on em0 proto tcp from any to any port 21 -> 127.0.0.1 port 8021 > > rdr on em1 proto tcp from any to any port 21 -> 127.0.0.1 port 8021 > > rdr on em2 proto tcp from any to any port 21 -> 127.0.0.1 port 8021 > > rdr on em3 proto tcp from any to any port 21 -> 127.0.0.1 port 8021 > > rdr on bge1 proto tcp from any to any port 21 -> 127.0.0.1 port 8021 > > > > ^^ Those are it. Do you see a rdr for the interface in question? > > > > On 9/13/05, Matthew Lenz <[EMAIL PROTECTED]> wrote: > > > On Tue, 2005-09-13 at 15:17 -0400, Scott Ullrich wrote: > > > > Okay so it sounds like the rdr rule for the interface is not being > > > > hit. Can you try editing /tmp/rules.debug and find the pftpx rule and > > > > modify it for the optional interface in question? > > > > > > > > Then issue pfctl -f /tmp/rules.debug and test again. If this is the > > > > problem it should be an easy fix. > > > > > > modify it in what way? I know jack and squat about pf. If you were > > > convinced I did then I fooled you some how. I looked through the > > > rules.debug .. here are the only ftp/pftpx related entries I can find: > > > > > > nat-anchor "pftpx/*" > > > > > > rdr-anchor "pftpx/*" > > > rdr on em0 proto tcp from any to any port 21 -> 127.0.0.1 port 8021 > > > rdr on em1 proto tcp from any to any port 21 -> 127.0.0.1 port 8021 > > > rdr on em2 proto tcp from any to any port 21 -> 127.0.0.1 port 8021 > > > rdr on em3 proto tcp from any to any port 21 -> 127.0.0.1 port 8021 > > > rdr on bge1 proto tcp from any to any port 21 -> 127.0.0.1 port 8021 > > > > > > anchor "ftpproxy" > > > anchor "pftpx/*" > > > pass in quick on bge0 inet proto tcp from port 20 to (bge0) port > 49000 > > > user proxy flags S/SA keep state label "FTP PROXY: PASV mode data > > > connection" > > > > > > I also looked for different occurrences of 'ftp, 21, 20' but nothing > > > came up.. above is all there is. > > > > > > -Matt > > > > > > > On 9/13/05, Matthew Lenz <[EMAIL PROTECTED]> wrote: > > > > > i logged in and killed the pftpx server.. and restarted it with full > > > > > debugging. when i hit an ftp site from LAN net machine .. i see it > > > > > proxying everything. however, when I attempt it from the OPT net > > > > > machine i see nothing. Its being blocked by the firewalls default > > > > > rule > > > > > for some reason. Here is the masked (removed my private ips) log > > > > > output: > > > > > > > > > > ------ > > > > > > > > > > pf: 23. 996387 rule 254/0(match): block in on em2: > > > > > WWW.WWW.WWW.WWW.44635 > > > > > > 127.0.0.1.8021: S 3451987609:3451987609(0) win 5840 <mss > > > > > 1460,sackOK,timestamp[|tcp]> > > > > > > > > > > WWW.WWW.WWW.WWW is the machine's private 'OPT2 net' ip from which I'm > > > > > trying to ftp to a public internet site. > > > > > > > > > > ------ > > > > > > > > > > pf: 28. 305486 rule 7.512.2.0/0(match): pass in on em0: > > > > > XXX.XXX.XXX.XXX.34073 > 204.152.191.7.45538: S > > > > > 3266523314:3266523314(0) > > > > > win 5840 <mss 1460,sackOK,timestamp[|tcp]> > > > > > > > > > > pf: 000022 rule 7.512.2.1/0(match): pass out on bge0: > > > > > YYY.YYY.YYY.YYY.57236 > 204.152.191.7.45538: S > > > > > 3266523314:3266523314(0) > > > > > win 5840 <mss 1460,sackOK,timestamp[|tcp]> > > > > > > > > > > pf: 270761 rule 7.512.2.0/0(match): pass in on em0: > > > > > XXX.XXX.XXX.XXX.43600 > 204.152.191.7.27258: S > > > > > 3270933157:3270933157(0) > > > > > win 5840 <mss 1460,sackOK,timestamp[|tcp]> > > > > > > > > > > pf: 000016 rule 7.512.2.1/0(match): pass out on bge0: > > > > > YYY.YYY.YYY.YYY.58700 > 204.152.191.7.27258: S > > > > > 3270933157:3270933157(0) > > > > > win 5840 <mss 1460,sackOK,timestamp[|tcp]> > > > > > > > > > > XXX.XXX.XXX.XXX is my machine on 'LAN net' connecting via ftp to > > > > > mirrors.kernel.org (204.152.191.7) site with mozilla. > > > > > > > > > > YYY.YYY.YYY.YYY is my firewalls public WAN interface ip > > > > > > > > > > ------ > > > > > > > > > > According to status.php all non-WAN interfaces have an pf rdr for ftp > > > > > to > > > > > 127.0.0.1 on port 8021 > > > > > > > > > > ... > > > > > > > > > > One observation that doesn't really have anything to do with this > > > > > stuff > > > > > but shouldn't pftpx be using the same public CARP ip/interface I have > > > > > all my other outbound NAT being mapped to? I guess that would only be > > > > > important if pftpx supports pfsync but from an consistency standpoint > > > > > it > > > > > might be better to run multiple pftpx servers one for each network > > > > > that > > > > > has outbound NAT mapped to a different public IP. Its not technically > > > > > NAT but the reasons for wanting all your connections coming from the > > > > > same IP is understandable. > > > > > > > > > > -Matt > > > > > > > > > > On Tue, 2005-09-13 at 14:11 -0400, Scott Ullrich wrote: > > > > > > I think this has something to do with the way our multiple gateways > > > > > > work. Since pftpx traffic isn't being affected by route-to since > > > > > > its > > > > > > coming from the local machine. Maybe Bill can chime in here. > > > > > > > > > > > > Scott > > > > > > > > > > > > > > > > > > On 9/13/05, Matthew Lenz <[EMAIL PROTECTED]> wrote: > > > > > > > yeah.. thats what scott's instructions say. which I did before > > > > > > > saying > > > > > > > that it didn't work :) > > > > > > > > > > > > > > -Matt > > > > > > > > > > > > > > On Tue, 2005-09-13 at 12:22 -0500, Erik Kristensen wrote: > > > > > > > > Log into command line and run pftpx. > > > > > > > > > > > > > > > > -Erik > > > > > > > > > > > > > > > > > > > > > > > > On Tue, 13 Sep 2005 12:13:37 -0500, Matthew Lenz wrote > > > > > > > > > Nope. I can still ftp just fine from a box on my LAN net .. > > > > > > > > > But > > > > > > > > > can't ftp out from my OPT2 net. I can http and ntp out from > > > > > > > > > my OPT2 > > > > > > > > > net just fine. > > > > > > > > > > > > > > > > > > -Matt > > > > > > > > > > > > > > > > > > On Tue, 2005-09-13 at 11:21 -0400, Scott Ullrich wrote: > > > > > > > > > > Does "killall pftpx && pftpx" from the shell fix it? > > > > > > > > > > > > > > > > > > > > Scott > > > > > > > > > > > > > > > > > > > > On 9/12/05, Matthew Lenz <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > I've a: > > > > > > > > > > > > > > > > > > > > > > * LAN net * * * Default LAN -> any > > > > > > > > > > > > > > > > > > > > > > for my LAN.. but on OPT 2 I've got: > > > > > > > > > > > > > > > > > > > > > > TCP/UDP OPT2 net * hostaliashere 21 (FTP) > > > > > > > > > > > TCP/UDP OPT2 net * hostaliashere 20 > > > > > > > > > > > > > > > > > > > > > > I can ftp anywhere I want on from the LAN network but I > > > > > > > > > > > cannot for the > > > > > > > > > > > life of me get ftp to work on OPT 2. Any ideas on what > > > > > > > > > > > to check? I've > > > > > > > > > > > taken a look at the status.php page to make sure all the > > > > > > > > > > > rules are being > > > > > > > > > > > added and that the hostalias is translated into the > > > > > > > > > > > correct internet ip. > > > > > > > > > > > Everything looks perfect but its a no go (yeah I have > > > > > > > > > > > outbound nat > > > > > > > > > > > enabled for all my LAN/OPT interfaces. I am accessing > > > > > > > > > > > internet ntp and > > > > > > > > > > > internet http sites just fine from these networks. > > > > > > > > > > > > > > > > > > > > > > -Matt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
