The dst-nat approach seems like it ought to work, but it seems that it does not in fact work.
Not sure what is not working, but the dst-nat approach DOES work, as I've used it here.
I use packet marking extensively, and I've tested the above with redirection to a web site both inside and outside of my network to no avail. The remote web site seems not to get the request. I've disabled the ip web-proxy to make sure that feature was not interfering.
Action on the dstnat rule will be dst-nat.
There must be some additional configuration required to make this work -- but what?
Not sure what you mean by "additional", but here is the overview of what has to happen:
1. You must be able to ID the traffic. You can use ip address, interface name (for pppoe connections), whatever else the firewall code can match on.
2. The interface that the customer traffic enters on CANNOT be the same as the "redirected" packet is going to leave the router on.
3. The webserver must be configured to reply with your "you didn't pay" page for both the
http://ip.add.ress.here request as well as it's "404" page. There can be no other webservers "listening" on that IP address, because the packet will arrive with what will be considered "invalid" http/1.1 headers.
4. If you are dropping all other traffic, you will want to insure that you accept tcp/80 (http) and udp/53 (dns) traffic prior to dropping the other stuff.
5. put in the dst-nat rule and it should work.
Has anyone actually done this and had it work?
MANY times.