No, not anymore, and it normally wouldn't be (the client reach the gateway through normal routing). The gateway *could* reach the client back on eth2 (and it does for IPsec and NAT-T packets, by writing a packet with destination MAC address of the host that sent it). Normally you'd think "well, silly-goose, that's your problem" (and normally I'd agree). For a real-live gateway with multiple external interfaces (and no dynamic routing), one static default gateway (out eth1), the other external interface won't have a default route (because.... default, by definition). This 2nd external interface is where VPN connections will terminate.
But again, it works for IPsec and NAT-T. The new packet on the wire is the MAC of the ingress next-hop that sent the frame (I even see this MAC address tracked in the zdebug with "-m VPN + all"; that's really clever!)
Here, the host Hades is *my* local LAN router, not the Check Point firewall (eth2 just happens to be the same). 10.0.3.236 is my client. 10.233.31.80 is the firewall's eth2. Hades eth2 MAC addr ends in "b0:4b". Hades is between my client and the firewall.
[root@hades ~]# ifconfig eth2
eth2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.233.31.30 netmask 255.255.255.0 broadcast 10.233.31.255
ether 00:0c:29:18:b0:4b txqueuelen 1000 (Ethernet)
[root@hades ~]# tcpdump -nni eth2 host 10.0.3.236 -e
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes
15:01:27.652944 00:0c:29:18:b0:4b > 00:0c:29:7a:76:63, ethertype IPv4 (0x0800), length 118: 10.0.3.236.54508 > 10.233.31.80.4500: UDP-encap: ESP(spi=0x1120e857,seq=0x31), length 76
15:01:27.677150 00:0c:29:7a:76:63 > 00:0c:29:18:b0:4b, ethertype IPv4 (0x0800), length 118: 10.233.31.80.4500 > 10.0.3.236.54508: UDP-encap: ESP(spi=0x59f1983d,seq=0x23), length 76
When it came to topology and xauth... crickets (well, as far as "doing the right thing" is concerned): [this was earlier in the day, hence the time difference]
[det@hades ~]$ sudo tcpdump -nni eth2 host 10.0.3.236
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes
10:46:08.183726 IP 10.0.3.236.49674 > 10.233.31.80.443: Flags [S], seq 3336228268, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 875756382 ecr 0,sackOK,eol], length 0
10:46:12.186856 IP 10.0.3.236.49674 > 10.233.31.80.443: Flags [S], seq 3336228268, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 875760382 ecr 0,sackOK,eol], length 0
10:46:12.957761 IP 10.0.3.236.49676 > 10.233.31.80.443: Flags [S], seq 2415593851, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 875761152 ecr 0,sackOK,eol], length 0
>>> here is where i noticed that NAT-T was actually working from the beginning:
10:46:12.960337 IP 10.0.3.236.55873 > 10.233.31.80.4500: NONESP-encap: isakmp:
10:46:12.977206 IP 10.233.31.80.4500 > 10.0.3.236.55873: NONESP-encap: isakmp:
>> but more crickets for XAuth/topology:
10:46:13.031651 IP 10.0.3.236.49676 > 10.233.31.80.443: Flags [S], seq 2415593851, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 875761223 ecr 0,sackOK,eol], length 0
10:46:13.066552 IP 10.0.3.236.49676 > 10.233.31.80.443: Flags [S], seq 2415593851, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 875761253 ecr 0,sackOK,eol], length 0
10:46:13.099089 IP 10.0.3.236.49676 > 10.233.31.80.443: Flags [S], seq 2415593851, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 875761283 ecr 0,sackOK,eol], length 0
10:46:13.128996 IP 10.0.3.236.49676 > 10.233.31.80.443: Flags [S], seq 2415593851, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 875761313 ecr 0,sackOK,eol], length 0
10:46:18.587032 IP 10.0.3.236.64964 > 10.233.31.80.4500: NONESP-encap: isakmp: child_sa #67[IVR]
10:46:18.588131 IP 10.233.31.80.4500 > 10.0.3.236.64964: NONESP-encap: isakmp:
10:46:20.250705 IP 10.0.3.236.64964 > 10.233.31.80.4500: NONESP-encap: isakmp: phase 1 I ident
10:46:20.252367 IP 10.233.31.80.4500 > 10.0.3.236.64964: NONESP-encap: isakmp: phase 1 R ident
10:46:20.252995 IP 10.0.3.236.49674 > 10.233.31.80.443: Flags [S], seq 3336228268, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 875768383 ecr 0,sackOK,eol], length 0
10:46:20.259071 IP 10.0.3.236.64964 > 10.233.31.80.4500: NONESP-encap: isakmp: phase 1 I ident
10:46:20.306897 IP 10.233.31.80.4500 > 10.0.3.236.64964: NONESP-encap: isakmp: phase 1 R ident
(of course ISAKMP couldn't get far because xauth never completed...)
Sooooo, das boog?