make, it complains about -I(TOP).log body in my rules but the body of the packet isn't getting logged.
interface/32, 0/0 or 0/32, and it doesn't work!
Try addingflags Sto each one of your TCP rules that haskeep statein it.
What might be happening is you're getting state entries for more than just the first packet of each connection and your state table is filling up. Previous versions of IPF did this when a packet arrived slightly out of window - it would not associate it with the state entry. The solution was to only add a state table entry for those packets with a SYN flag.
This should no longer be required. However, many users will tell you it is a good security practice to useflags Swith TCP rules anyway.
See above.
This is done because depending on your ruleset, a new rule added may not be affective based on old rules, and also because the script reads in the entire ruleset anyway, so it will prevent duplicates. The script usesipf -Fawhich flushes rules but not state table entries. To flush state table entires useipf -FS.
You're probable blocking stuff to your ident port, 113. Change that rule so that you send a TCP reset:
block return-rst in quick on ppp0 proto tcp from any to any port = 113Solaris users, see VII-1
See above.
Make sure you have a kernel that has been correctly patched using the patches supplied with IP Filter, has "IPFILTER" in the config file and is the current kernel you are using.
For FreeBSD/NetBSD, you will need to load if_ipl.o in an rc script (when securelevel is 0) or make sure that securelevel is -1 at runtime.
make, it complains about -I(TOP).You're using the GNU version of make. Use the standard version of make that comes with your operating system.
For the purposes of explaining this, lets take the following example:
(internet)--->(if0[OS]if1)----|----(httpd on 192.168.0.2) | |----(browser on 192.168.0.3)if0 is some.isp.ip.addr
if1 is 192.168.0.1
I have a rdr on the external interface, written as:
rdr if0 0.0.0.0/0 port 80 -> 192.168.0.2 port 80
Now, IPFilter's rdr function does not natively support "bouncing" the connection (i.e. a packet coming in and leaving the same interface). The redirection happens only to packets coming in on the external interface. If you want to surf to 192.168.0.2 from the browser on 192.168.0.3, you can either do so directly via http://192.168.0.2/ (or by a CNAME in your DNS), or by using a "bounce" utility on the firewall to reflect inbound packets on if1 towards 192.168.0.2. By nature neither the OS nor ipf will do this for you. If you search the ipf archives you will find some bounce utilities. The golden RDR rule: rdr works *only* when the packet traverses the firewall (i.e. in one interface and out on another interface).
You probably have anipf.confrule that looks something like:
block return-rst in on ext-interface proto tcp allA rule like this will send an RST in response to an out-of-sequence ACK from the other end of a long ftp transfer, breaking the connection. Try replacing your rule with:
block in on ext-interface proto tcp allwhich will send RST only to SYN packets.
block return-rst in on ext-interface proto tcp all flags S
Add a second ftp proxy rule to your ipnat.conf:
map ext-interface firewall-ip/32 -> firewall-ip/32 proxy port ftp ftp/tcp
It isn't possible to map ports on ICMP packets. Hence, once a state table entry is set up to a particular target, only one machine can ping that target until the state table entry expires.
For TCP and UDP, portmapping allows simultaneous connections to external targets from multiple machines in the LAN.
There will supposedly be a workaround for this in the 4.x series.
There may be many reasons for this including that mentioned in question 1 of this section. However, there are other possibilities such as you have a very busy firewall and you're filling the state table. For this you have a few options: you can enlarge the state table, tweak some IPF values, or both. See the III-25 for details on enlarging the state table. Here are some values to tweak though.
ipf.fr_tcpidletimeout=7200
ipf.fr_tcpclosewait=120
ipf.fr_tcplastack=120
ipf.fr_tcptimeout=240
ipf.fr_tcpclosed=60
ipf.fr_tcphalfclosed=300
ipf.fr_udptimeout=90
ipf.fr_icmptimeout=35
These values will be in very different places depending on your OS, such as/etc/rc.sysctl,/etc/sysctl.conf, or/etc/system.
log body in my rules but the body of the packet isn't getting logged.
You need to use the -b command line option to ipmon.
The IPF How-To gives a good explanation of this. The client will try to connect to the server's internal IP address because that's the way passive FTP works: the server tells the client its IP address in the payload and the client connects to it.
The solution is to explicitly tell your FTP server what to report as its IP address, and give it a range of ports to give out as well. You will then need to redirect traffic from those ports on your IPF box to the FTP server. Each FTP server is different, and you'll need to read the manual for your specific software, but to give an example, you can specificy this information in WU-FTPd's configuration file as follows:passive ports 0.0.0.0/0 32768 49151
passive address your.pub.IP.addr 0.0.0.0/0
At the time of writing, it's been reported that Microsoft IIS's FTP server is not capable of being configured this way. However, most Unix FTP servers should have an option for this somewhere.
If you use a rule like:
rdr x.x.x.x port 80 -> y.y.y.1,y.y.y.2,y.y.y.3 port 80 tcp round-robin
You will get an error likemissing fields - 2nd port (,). This is because you can't put more than two hosts on a single round-robin line. You need to reformat it like this:
rdr x.x.x.x port 80 -> y.y.y.1,y.y.y.2 port 80 tcp round-robin
rdr x.x.x.x port 80 -> y.y.y.3 port 80 tcp round-robin
or better yet like:
rdr x.x.x.x port 80 -> y.y.y.1 port 80 tcp round-robin
rdr x.x.x.x port 80 -> y.y.y.2 port 80 tcp round-robin
rdr x.x.x.x port 80 -> y.y.y.3 port 80 tcp round-robin
The two examples above act exactly the same, but notice that the second example is much easier to manage. If one of your servers goes down, it's very easy to take it out of the loop quickly with the second example. In the first example, if y.y.y.1 or y.y.y.2 goes down, and you take that line out, you loose two hosts.
When troubleshooting problems with ipnat remember that rules are process by network size. So a /32 rule will always be applied before a /24 rule, etc. Therefore a ruleset like:
map ext-interface x.x.x.x/24 -> y.y.y.y/32 proxy port ftp ftp/tcp
bimap ext-interface x.x.x.a/32 -> y.y.y.y/32
bimap ext-interface x.x.x.b/32 -> y.y.y.y/32
The proxy rule will never get matched. Therefore, if you need your bimap rules to be /32, then your proxy rule will need to be /32 to as well. Albeit a pain, the following is the only way to fix the problem:
map ext-interface x.x.x.a/32 -> y.y.y.y/32 proxy port ftp ftp/tcp
map ext-interface x.x.x.b/32 -> y.y.y.y/32 proxy port ftp ftp/tcp
...
bimap ext-interface x.x.x.a/32 -> y.y.y.y/32
bimap ext-interface x.x.x.b/32 -> y.y.y.y/32
This way the proxy rules will match instead of getting skipped over.
interface/32, 0/0 or 0/32, and it doesn't work!
These special aliases do not work in IPF rules, or in IPNat rdr rules. They only work in IPNat's map and bimap rules.
Chances are you are using IPF as a loadable kernel module. If not, then you want:
ipf -D
Which will disable the filter. However, if you are using a loadable kernel module, that option is not available to you. You can unload the module, but it will get reloaded the next time the device associated with IPF is accessed. So your best bet is to switch to an empty rulset:
ipf -s
That assumes your other ruleset actually is empty. Alternatively, you could unload the modules, and then mv the modules out of the way. This is a bit ugly, but it will work as a temporary way of keeping IPF out of the way for testing.
The Cisco VPN Concentrators are often configured to expect a source port of 500 in addition to the destination port of 500. Since NAT, by default, changes the source port, this breaks. Add a line like so:
map le0 from x.x.x.x/24 port=500 to ip.of.vpn/32 -> a.b.c.d/32
to your ipnat.conf.
If you try to remove an entry from an ippool and getremove_pool:SIOCLOOKUPDELNODE: No such file or directory, you're running an older version of IP Filter 4. This bug is fixed in recent versions.
At the time of writing, this bug was in the IP Filter included with Solaris 10. If y ou are using this version your options are upgrade to the open-source version of IP Filter, or file a bug with Sun.