PPPoE problems with NAT/Routing

[DH]

Hi,
I have a strange problem:
I configured a PPPoE interface on gaia - without DNS and default gateway. The IP is static, but set by the ISP.
This works so far, the interface came up and get the IP address.
Under CP-SmartCenter I defined the pppoe-interface(pppoe1) with a topology based on routing.
Then I define a static route for a single host (x.x.x.x/32) by the pppoe interface - for testing. - I do not have a stactic next hop IP.
The route is shown under 'show route' and 'ip r l'.
In global properties outgoing traffic from gateway is allowed first.
I try to ping this destination IP (x.x.x.x/32) from the gateway.
But as long as checkpoint run. I'm not able to ping the destination of that route.
In the smartlog the traffic is accepted, without any NAT-rule. Which should by okay, because I use the gateway as source. But I see the main IP of the gateway as source, not the outgoing IP.
I don't see the packets incoming at the destination. I already changed the type of the interface to external, same result.
by tcpdump -i pppoe1 -n -v on the gateway it seems there isn't any outgoing package, too. I only see the encapsulated packets.
I already did fwaccel off, but this didn't help, too.
When I stop the checkpoint services the ping works.

Version:
R81.20 JHF take 26

My questions:
- In my opinion packets originated from gateway, should use outgoing IP as source, don't they? - If CP-services stopped, it is so.
- When I have multiply external interfaces and a automatic NAT-rule hide behind gateway, will the outgoing interface IP be used as source IP based on routing or simply the 1st external?
- Any idea why that do not work with running CP-Services?

[Chris_Atkinson]

The last time I did PPPoE on full GAiA i used an interface address of 0.0.0.0/32 in the external interface topology definition to overcome similar challenges which should result in it dynamically resolving the ISP assigned IP.

The default route is set via interface pppoe1 rather than a next-hop IP.

Regarding the NAT elements you might be able to reference similar logic i.e. a 0.0.0.0/32 host object or LocalMachine object.

[DH]

My problem is, that I need specific routes by pppoe1 in target, because the default route is used on a other interface.
In gaia I already set the static route by interface pppoe1 this seems work - until I start the CP services...
So routing seems be okay.
I can try to define a topology group for the target IPs on the interface in opposide to routing based, but my problem is, that even if the pppoe1 interface is not configured inside smartcenter routing thru this interface will not work as long as the CP services run, And with configured interface I didn't see any Anti spoofing messages. It seems the gateway ignores the existing routes when the CP services are running...
I do not understand this...

[Chris_Atkinson]

The interface topology must be set inside the gateway object and the policy pushed, again setting the IP as 0.0.0.0/32 here should account for it being dynamic.

As an example If the interface is set as external and the targets referenced by your routes are external IPs you should not have spoofing issues or need to specify a group like you are describing in order to have traffic work. 

How is the NAT configured?

[DH]

NAT is configured as hide behind gateway.
So far I had set the (static) IP from the ISP to the interface inside the gateway-object. I tried with 0.0.0.0/32, but the result is the same.
At the moment I try to ping from the gateway itself to the target IP of the PPPoE routing, so it should use the outgoing public IP.
But a fw monitor with the target IP on the gateway with -p all (fw monitor -p all -e 'accept host(x.x.x.x/32);') do not show an traffic! - and I do not see any log inside SmartLog for this, too. Logging of implied rules is enabled.
So for me it seems, that there is no traffic generated inside the firewall...

[Chris_Atkinson]

Ack. Sorry in my skim reading I've overlooked that you are using a static address in which case this should all be very much simpler config wise.

In such cases usually about as complicated as it gets is ensuring tcp clamping is enabled to contend with possible MTU issues.

PPPoE and SecureXL don't mix so you could investigate disabling it (if not already) for testing / isolation purposes if you get really stuck otherwise it may need to be looked at more closely by TAC.

[DH]

fwaccel is already off - for testing

mss_clamp is true (in the CP registry for the gateway).
Even if there is trouble with it, I think I should see traffic in fw monitor...because the outgoing packet should have been created.

the ping is only 64byte and without CP it works, that is the strange thing...

[Chris_Atkinson]

Noted, indeed MSS clamping isn't relevant to basic ping traffic flows.

Does this gateway handle any VPNs?

[PhoneBoy]

PPPoE interfaces are NOT accelerated by SecureXL in maintrain Gaia.
However, you don't need to disable SecureXL anymore (as of R80.20), we just don't accelerate traffic going to/from a PPPoE interface.