First up, I realized over the weekend that though I had begun using
2.6 IPsec, I hadn’t altered my usual set of iptables firewall rules
which refer to ipsec0. 2.6 IPsec doesn’t use a “virtual device”
for its IPsec tunnels, so saying things like “make sure this kind of
traffic only comes in over an IPsec tunnel” becomes kind of wonky.
A quick note on how 2.6 IPsec interacts with Netfilter (and therefore
iptables) as of about 2.6.6 or so (FC2 kernel). Packets are encrypted
before the NF_IP_POST_ROUTING hook. This means that when
forwarding a packet over an IPsec connection, the NF_IP_FORWARD
and NF_IP_LOCAL_OUT hooks see the packets unencrypted, but any
(for example) SNAT rules you have will see the ESP packet. (BTW, I
only use ESP in tunnel mode. All of this documentation assumes that,
though most everything applies to other IPsec modes as well.)
So how do you ensure that packet X came in via IPsec? Currently the
hackish way to do this seems to depend on the fact that an nfmark set
on an incoming IPsec packet will be the same nfmark seen on the
resulting decrypted packet. So, for example, iptables -t mangle -A
PREROUTING -p esp -j MARK --set-mark 1 to mark ESP packets as they
come in, then match with -m mark --mark 1 elsewhere. If you use
nfmark for other things perhaps you need a different nfmark value.
This is all icky IMHO. I don’t like using nfmark, especially since
the patch to allow more complex operations on nfmark (like bitwise or)
isn’t in the iptables nor kernel proper. The semi-good news is that
there is a patch in the pipeline to make this kind of matching sane.
Check out the IPsec-related patches in the Netfilter patch-o-matic
extra
repository.
There are four or so for IPsec that fix up the way packets traverse
Netfilter hooks. These patches make it more sane, and different
enough from what I’ve covered above. Go hit up a mail archive for
netfilter-devel and read the thread(s) on “NAT and IPsec” (IIRC).
You’ll also find a “policy” patch which should be the patch that
allows you to “match the IPsec policy used for handling a packet.”
You can find usage examples on the netfilter-devel list too, I
believe. I haven’t used these patches, and I might not as long as
they’re not integrated into the base iptables and base kernel.
In other news, I’m charged with testing out a client’s video
conferencing appliance which sits behind a Linux box doing NAT to
their single routeable IP. I, too, am in this situation, but
trying to connect to their appliance with NetMeeting (rather than
another appliance). Same concept, though: H.323 still hates NAT. I
gather there is something like H.245 which is some sort of tunneling
that probably gets around some of these problems, blah blah blah,
uninformed rambling. NetMeeting doesn’t support this tunneling
protocol last I heard, though, so for now I struggle on. (Maybe I
should try GnomeMeeting. I think it supports this tunneling protocol
which I may or may not be fabricating entirely.)
So I go about trying to stick an H.323 gatekeeper on my Linux NAT box
here. GnuGk was a prominent search result so
I gave it a go. Its included RPM spec file didn’t go over so well, so
here’s my GnuGk 2.0.8
SRPM.
I built this on Fedora Core 1 i386. Note the large number of packages
required for build and what you suppose is their irrelevance to the
very basic set of features you’re installing. SDL? What? This is a
daemon. LDAP? Even though I turned it off? I think all these extra
libraries are a result of GnuGk using the PWLib build “system,” which
by the by I think FC1 might have a little screwed up. Either that or
GnuGk uses it in a bastardly way. Anyway, it builds, and it runs.
I’ll admit I haven’t been using it much, and the init script might
need some work still. I accept patches.
You’ll need an /etc/gnugk.ini after building and installing GnuGk.
Check out section 7.2.1 of the GnomeMeeting
FAQ.
Two things I had to modify for GnuGk 2.0.8. First,
[RasSvr::ARQFeatures] needs to be [RasSrv::ARQFeatures].
Second, under the [RasSrv::ARQFeatures] section, add
ParseEmailAliases=1 as an option. Without this option, you can’t
do things like place a call from NetMeeting to @1.2.3.4 which is
what GnomeMeeting suggests you try, I believe. Also note that this
configuration seems to be open to some mischief from others.
Particularly, the interactive status port is open to all through that
rule=allow line, I do believe, and you can change things (or at
least disconnect calls) from this port I think.
For instructions on how to configure NetMeeting, see
http://www.gnugk.org/netmeeting.html. Note that (I hope) you don’t
have to put in both a phone number and a user name. I just entered a
user name. After I did this setup, I was able to connect to the
gatekeeper and instruct it to “dial out” to the remote VC unit. I
wasn’t able to connect to the remote VC unit, though, and I think that
might be the remote end’s fault. The remote network, at this point,
has no gatekeeper. I’m trying to figure out if I need to add one or
not. It simply has a butt-load of ports forwarded in to it. For the
curious, the appliance on the remote end is a Polycom unit. I think
I’m going to need to figure out which Polycom unit and see if I can’t
remotely reconfigure it. I suspect it has some NAT settings hiding
around in its interface that needs to be twiddled, for starters.
On a note related to both of the topics covered in this entry,
somewhat, there does seem to be an H.323 NAT module in the Netfilter
POM-NG extra
repository.
A possible alternative to using a gatekeeper, at least in my
situation(s).