Source routing / NAT? question

[gswallow]

Heya,

After beating my head against the wall on this issue for, really, too long a time, I'm throwing in the towel.

We're running Checkpoint SPLAT in HA mode, on HP servers (not that the server manufacturer matters). It's not Pro, it's not VSX, and it's running the 2.4 kernel.

# ver
This is Check Point SecurePlatform NGX (R65) Build 123

# uname -a
Linux xx 2.4.21-21cpsmp #1 SMP Sun Feb 11 18:18:33 IST 2007 i686 i686 i386 GNU/Linux

We're not running pro or anything advanced:

# pro
SecurePlatform Pro disabled
Usage: pro enable
       pro disable

This is our network layout:

# ifconfig -a | grep -C1 -i hwaddr
eth0      Link encap:Ethernet  HWaddr 00:1B:78:5C:5C:A2
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
--

eth0.52   Link encap:Ethernet  HWaddr 00:1B:78:5C:5C:A2
          inet addr:XX.40.249.21  Bcast:XX.40.249.31  Mask:255.255.255.240
--

eth0.53   Link encap:Ethernet  HWaddr 00:1B:78:5C:5C:A2
          inet addr:XX.40.249.34  Bcast:XX.40.249.47  Mask:255.255.255.240
--

eth0.998  Link encap:Ethernet  HWaddr 00:1B:78:5C:5C:A2
          inet addr:XX.40.247.21  Bcast:XX.40.247.63  Mask:255.255.255.192
--

eth1      Link encap:Ethernet  HWaddr 00:1B:78:5C:5C:A3
          inet addr:192.168.1.6  Bcast:192.168.1.255  Mask:255.255.255.0
--

eth2      Link encap:Ethernet  HWaddr 00:1B:78:5C:5C:B8
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
--

eth2.2    Link encap:Ethernet  HWaddr 00:1B:78:5C:5C:B8
          inet addr:10.254.2.2  Bcast:10.254.2.255  Mask:255.255.255.0
--

eth2.3    Link encap:Ethernet  HWaddr 00:1B:78:5C:5C:B8
          inet addr:10.254.3.2  Bcast:10.254.3.255  Mask:255.255.255.0
--

eth3      Link encap:Ethernet  HWaddr 00:1B:78:5C:5C:B9
          BROADCAST MULTICAST  MTU:1500  Metric:1
--

eth4      Link encap:Ethernet  HWaddr 00:1C:C4:68:AA:5A
          BROADCAST MULTICAST  MTU:1500  Metric:1
--

eth5      Link encap:Ethernet  HWaddr 00:1C:C4:68:AA:58
          BROADCAST MULTICAST  MTU:1500  Metric:1

eth0 is outside, partitioned into two vlans. eth1 is the management, and eth2 is inside, partitioned into two vlans. The idea is to segregate networks per customer, and account for traffic on a per-vlan basis. So, for instance, customer 1 gets vlans 2 and 52, while customer 2 gets vlans 3 and 53. I tried to use source routing and it just hasn't worked:

#!/bin/sh

/sbin/ip route add default via XX.40.249.17 dev eth0.52 table customer1
/sbin/ip route add default via XX.40.249.33 dev eth0.53 table customer2
/sbin/ip route add default via XX.40.247.1 dev eth0.998 table localhost
/sbin/ip route delete default via XX.40.247.1

/sbin/ip rule add from 10.254.2.125/32 nat XX.40.249.26 lookup customer1
/sbin/ip rule add from 10.254.2.25/32 nat XX.40.249.25 lookup customer1
/sbin/ip rule add from 10.254.3.0/24 lookup customer2
/sbin/ip rule add iif lo lookup localhost
/sbin/ip rule add from 192.168.1.0/24 lookup localhost

/sbin/ip route flush cache

I've tried lots of variations on the rules, above. Variations include using "iif" rather than "from," using external IP addresses in the "from" part of the rule:

/sbin/ip rule add iif eth2.2 lookup customer1
/sbin/ip rule add from XX.40.249.25 lookup customer1

Also, I've toyed around with manual vs. automatic NAT, and messed around with NAT options in the policy global properties.

None of it works. I can actually *delete* the default route, and with the lo rules above connect to the firewall using SSH, but the policies fail to govern traffic passing through two VLANs. Am I just missing the point, or is this not possible?

Any help would be appreciated. Thanks!

[mcnallym]

SPLAT does not do Source Based Routing!

[chillyjim]

Yes SPLAT does support source/policy based routing. Check Point does not support its use.

You will need to perform all the NAT in the firewall rule base. I forget which order the NAT/Routing works though.

[gswallow]

Originally Posted by chillyjim

Yes SPLAT does support source/policy based routing. Check Point does not support its use.

You will need to perform all the NAT in the firewall rule base. I forget which order the NAT/Routing works though.

According to the policy global properties, you'd think that NAT happens before routing, since all NAT is done on the client side. Maybe I understand this too simply? Maybe initial packets are translated before routing and return packets are actually translated *after* routing? I know that I see internal addresses in return packets on external interfaces. They're just on the wrong VLAN.

In any case, none of the rules I tried worked; I even included rules like this:

ip rule add from 10.254.2.0/24 lookup customer1, which should have matched the internal network space. Still saw return packets on the wrong VLAN.

I wonder: could this be a kernel issue? Is it possible that SPLAT 2.6 supports PBR, and SPLAT 2.4 doesn't? Can you tell I'm in WAG (wild-assed guess) mode?