The most likely cause for the RST is because you are not keeoing state on the inbound HTTP request hence the out going packet gets natted and the other end doesn't like the different port number hence sends the RST or is being blocked by a firewall rule on ep0. If you have ipmon running and the log directive in your firewall rules in appropriate locations you should see the which rule is blocking it. Personally I think your problem is related to the former.
You will need a rule for ipf such as: pass in on tun0 proto tcp from any port > 1023 to 192.168.2.2 port = 80 flags S keep state Cheers, Larry. On Thu, 3 Apr 2003, Chris Meyer wrote: > Greetings all. Same old problem, slightly new twist: > > I've been having problems getting my redirect rules to work adequately. > I'm attempting to forward port 80 on my firewall/router (running FreeBSD > 4.6.2, ipf 3.4.31), which we'll call Fire (internal IP 192.168.2.1, > external IP dynamically assigned), over to my web server, which we'll > call Web (IP 192.168.2.2). > > Fire has two interfaces, ep0 (which is the link between it and Web), and > tun0 (which is a ppp connection to my DSL provider and thus to the big, > bad internet). For testing purposes I've turned off all ipf rules using > "ipf -Fa", which should default to "pass in all/pass out all" unless I'm > mistaken. My rules for ipnat are: > > rdr tun0 0.0.0.0/0 port 80 -> 192.168.2.2 port 80 > rdr tun0 0.0.0.0/0 port 81 -> 192.168.2.2 port 22 > map tun0 192.168.0.0/16 -> 0/32 portmap tcp/udp 10000:60000 > map tun0 192.168.0.0/16 -> 0/32 > > Now this is all fine and dandy. From the outside I can get into my > firewall on port 22 just fine, meaning that things are reaching the > destination and everything. However, when I try telnetting to ports 80 > or 81 the connection reads "Trying XXX.XXX.XXX.XXX..." and hangs there > (versus telnetting to a port that isn't open at all, where it > subsequently says "telnet: Unable to connect to remote host"). > > Looking at the traffic using tcpdump, here's what I see. On tun0: > > 13:56:28.147563 YYY.YYY.YYY.YYY.1043 > XXX.XXX.XXX.XXX.http: S > 4071114330:4071114330(0) win 57344 <mss 1452,nop,wscale > 0,nop,nop,timestamp 7051330 0> (DF) [tos 0x10] > > So the packet comes in but nothing ever gets sent back out. Okay.... On ep0: > > 13:57:46.604603 YYY.YYY.YYY.YYY.1044 > Web.http: S > 1266895710:1266895710(0) win 57344 <mss 1452,nop,wscale > 0,nop,nop,timestamp 7059176 0> (DF) [tos 0x10] > 13:57:46.605248 Web.http > YYY.YYY.YYY.YYY.1044: S > 557660198:557660198(0) ack 1266895711 win 65535 <mss 1460,nop,wscale > 1,nop,nop,timestamp 161899704 7059176> (DF) > 13:57:46.605595 YYY.YYY.YYY.YYY.1044 > Web.http: R > 1266895711:1266895711(0) win 0 > > So there's a Reset packet that gets sent for no apparent reason. The ACK > doesn't seem to be making it back out on tun0, so I'm assuming it's > getting lost somewhere in the firewall and something on there is sending > back a RST. > > Two more pieces which may serve to pull things together or obfuscate > further: > > 1) I've had to issue the ppp command with the -nat flag when I connect > to my DSL provider; I don't know if this would be responsible for this > behavior, but things don't seem to get routed properly to my internal > machines without it. > > 2) There is one place from outside that works just fine, and that would > be my workplace. I habitually ssh into my home network from there, and > I've found that whether there are any other connections or not I can get > to ports 80 and 81 just fine and be properly redirected. Nowhere else on > the internet (from the four or five sample points I've taken, at least) > can succeed in getting passed through, however. > > Any ideas what's going on here? I found two other messages similar to > what I'm experiencing after poking through archives, at > http://marc.theaimsgroup.com/?l=ipfilter&m=102144256827754&w=2 and > http://marc.theaimsgroup.com/?l=ipfilter&m=93847700924536&w=2 from 2002 > and 1999, respectively. Neither of those threads offered any help to > speak of. > > Thanks for any help anyone can give, > -Chris > > > >
