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).