@@ -86,103 +86,4 @@ iptables firewall setup
8686=======================
8787
8888The included ` launch_tcpcryptd.sh ` script adds iptable rules to divert all TCP
89- traffic -- * except* that which is already encrypted, like SSH -- to tcpcryptd.
90- Read on only for more complex firewall setups.
91-
92- The naive way to use tcpcryptd:
93-
94- iptables -A OUTPUT -p tcp -j NFQUEUE --queue-num 666
95- iptables -A INPUT -p tcp -j NFQUEUE --queue-num 666
96-
97- This will apply tcpcrypt to all locally destined (or generated) TCP packets.
98- This will work, but you'll run into problems #1 and #2 , which may not be
99- problems if you don't have a firewall or nat setup.
100-
101- For testing on your local machine, you can restrict tcpcrypt to the loopback interface:
102-
103- iptables -A OUTPUT -p tcp -o lo -j NFQUEUE --queue-num 666
104- iptables -A INPUT -p tcp -i lo -j NFQUEUE --queue-num 666
105-
106- Or, to run tcpcrypt only on port 80, use this (taken from launch_tcpcryptd.sh):
107-
108- iptables -A OUTPUT -p tcp -m tcp --dport 80 -j NFQUEUE --queue-num 666
109- iptables -A INPUT -p tcp -m tcp --sport 80 -j NFQUEUE --queue-num 666
110-
111- To restore your iptables rules to their previous state, you can remove rules by
112- replacing ` -A ` (append) with ` -D ` (delete) in the above commands.
113-
114- The following instructions apply to using tcpcrypt on firewall/gateway boxes.
115-
116- Linux firewall setup is more challenging than on FreeBSD for two reasons.
117-
118- 1 . In FreeBSD, after a packet is diverted, the divert daemon can drop the
119- packet, or accept it. In the latter case, firewall processing continues
120- from the next rule. So basically natd will get a chance to run, and other
121- firewall rules. It's a pipeline. On Linux, you can either accept or drop
122- the packet, which ignores the rest of the firewall.
123-
124- 2 . In FreeBSD, you can easily order tcpcryptd, then natd, because they're
125- both in userland, and both use divert, and the whole firewall is a
126- pipeline. On Linux natd is IP connection tracking in the kernel, which is
127- used for stateful firewalls too. We gotta make tcpcryptd run BEFORE
128- conntrack.
129-
130- To make tcpcrypt work the "proper" way, making sure that nat and stateful
131- firewalls (e.g., -m state --state ESTABLISHED) work:
132-
133- iptables -t raw -A PREROUTING -p tcp -j NFQUEUE --queue-num 666
134- iptables -t mangle -A POSTROUTING -p tcp -j NFQUEUE --queue-num 666
135-
136- This will apply tcpcrypt to all TCP packets entering and exiting the box,
137- including forwarded packets. Note that this setup will respect firewall
138- rules in other tables but terminate those in the raw and mangle tables. In
139- short, your firewall rules in the filter table and nat table (those that you
140- probably care about most) will work. You'll get caught by problem #1 though.
141-
142- To make tcpcrypt work the elite way, making sure that all firewall rules are
143- obeyed and conntrack isn't confused:
144-
145- iptables -t raw -N tcpcrypt
146- iptables -t raw -A tcpcrypt -p tcp -m mark --mark 0x0/0x10 -j NFQUEUE --queue-num 666
147- iptables -t raw -I PREROUTING -j tcpcrypt
148-
149- iptables -t mangle -N tcpcrypt
150- iptables -t mangle -A tcpcrypt -p tcp -m mark --mark 0x0/0x10 -j NFQUEUE --queue-num 666
151- iptables -t mangle -I POSTROUTING -j tcpcrypt
152-
153- And launch ` tcpcryptd ` with ` -x 0x10 `
154-
155- This example is like before, but will create a chain with only the tcpcrypt
156- rule, which will run only if a packet is unmarked. When tcpcryptd needs to
157- accept a packet, rather than passing a verdict of ACCEPT, which terminates
158- all rule processing, it will pass a verdict of REPEAT, which restarts
159- processing at the current chain. To avoid loops, it will also mark the
160- packet so that the rule to divert will be matched only once. Effectively the
161- first time round real work will be done, and the second time round we
162- "return" to process the other rules.
163-
164- Note that you can make tcpcryptd work transparently on forwarded traffic, and
165- even in conjunction with NAT. You can pretend that the Internet is
166- tcpcrypted. Lets say eth0 is your LAN. You can do something like:
167-
168- [ create the tcpcrypt chains as explained earlier.]
169-
170- iptables -t raw -A PREROUTING -i eth0 -j tcpcrypt
171- iptables -t mangle -A POSTROUTING -o eth0 -j tcpcrypt
172-
173- tcpcryptd will see all incoming traffic from eth0 and make it look like
174- standard TCP to the outside world, and will then tcpcrypt all the responses
175- coming back to eth0. There's one caveat though when using it in conjunction
176- with NAT (conntrack). tcpcryptd forges a packet (the INIT2) and this
177- confuses conntrack as it thinks it's a new connection and it changes the
178- source port. You therefore need to add:
179-
180- iptables -t raw -A OUTPUT -o eth0 -j NOTRACK
181-
182- i.e., all locally generated traffic (the forged packet from tcpcryptd) should
183- not be natted. In fact I don't even know why it is being natted (maybe a
184- bug). Of course you need to setup nat with something like:
185-
186- iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source 1.2.3.4
187-
188- where eth1 is your Internet interface and 1.2.3.4 your Internet static IP.
89+ traffic port 80 to tcpcryptd. See src/iptables.sh for details.
0 commit comments