Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Luigi_Vezzoso1
Collaborator

Distribute Office Mode IP ranges via BGP or OSPF

Is there a method to configure office mode VPN in interface mode? I need this configuration to require a static route for the VPN client IP ranges and redistribute them via BGP or OSPF.

8 Replies
Petr_Hantak
Advisor
Advisor

Not sure if it will work for you in cooperation with office mode, but I'm using following for normal L2L tunnel networks. I need to propagate them to BGP as well. So what I did is just create new static routes for requested network (office pool in your case). Route must be live in routing table when you want to propagate it, so as next-hop I'm using default default gateway IP address. Check Point recognizes that the traffic should be encrypted by VPND and then it will redirect it into tunnel no matter on local routing table.

It is not clear solution, but you can try it if you want.

0 Kudos
Luigi_Vezzoso1
Collaborator

tks for the suggestion. As far I know I don't need to specify static route for the the office mode vpns. Are you configure the L2L vpns in interface mode (route based) or policy based?

0 Kudos
Petr_Hantak
Advisor
Advisor

I'm using domain based model.

0 Kudos
Luigi_Vezzoso1
Collaborator

and what kind of route have you inserted? You haven't a default gateway to router the traffic through a specific gateway and/or interface

I.e.

Office Mode Lan: 10.10.10.0/24

I should have a static route 10.10.10.0/24 via ? and redistribute that via dynamic routing protocol

0 Kudos
Petr_Hantak
Advisor
Advisor

Well let's say that you have your office mode LAN: 10.10.10.0/24. Then you have on your firewall gateway for example default route via next hop IP address 15.15.15.10. 

Then you can put static route 10.10.10.0/24 via 15.15.15.10 into your firewall. In that case your network will be visible in routing table and could be advertised via BGP. Office mode IP pool is not visible in routing table by default. If you don't want to use some real address as next hop, then you can try dummy Loopback interface for example.

Unfortunately I can't test it right now if it works with office mode. Hope it will.

0 Kudos
Luigi_Vezzoso1
Collaborator

Do you think that creating those kind of rule with a fake gateway will worK? I think it's not correct because the nexthop for the remote office network is the firewall self.... 

0 Kudos
Petr_Hantak
Advisor
Advisor

Ok I just did a test. In my topology I have firewall gateway which is available for Endpoint VPN with office mode IP network 10.12.218.0/24. Endpoint clients calling public IP of my firewall via Internet.

Without solution Endpoint VPN works fine as usual and when you check routing table doesn't contain any route for 10.12.218.0/24 segment.

Let's apply workaround now. I added new static route for 10.12.218.0/24 via default gateway next-hop.

(Note: Basically it makes sense. When default gateway won't be reachable or interface is down, static for 10.12.218.0/24 disappear from routing table and can't be propagated via BGP as well. But when I haven't got internet, so no one from outside is able connect via Endpoint VPN, so there is no sense to propagate it as alive in the BGP as well.)

Now we have static route perfectly visible in routing table and we can share it via BGP. I tried to connect with test user and office mode worked fine as before with no change. Workaround works fine. Why? You can take a look on chain what is happening with the traffic when it goes via our firewall in case you have VPN active. You can see many actions regarding to VPN which are taken no matter on normal routing table, because VPN tagging take precedence. Firewall knows that is VPN traffic and local static route hasn't got impact on it.

GW> show route
Codes: C - Connected, S - Static, R - RIP, B - BGP,
       O - OSPF IntraArea (IA - InterArea, E - External, N - NSSA)
       A - Aggregate, K - Kernel Remnant, H - Hidden, P - Suppressed,
       U - Unreachable, i - Inactive

S         0.0.0.0/0           via X.X.X.169, eth1, cost 0, age 22919
S         10.12.218.0/24      via X.X.X.169, eth1, cost 0, age 10



GW> fw ctl chain
in chain (20):
        0: -7ffffff0 (f1850290) (00000001) tcpt inbound (tcp_tun)
        1: -7f800000 (f294a520) (ffffffff) IP Options Strip (in) (ipopt_strip)
        2: -7d000000 (f1858010) (00000003) vpn multik forward in
        3: - 2000000 (f183dc70) (00000003) vpn decrypt (vpn)
        4: - 1fffff8 (f1848d00) (00000001) l2tp inbound (l2tp)
        5: - 1fffff6 (f294bcd0) (00000001) Stateless verifications (in) (asm)
        6: - 1fffff5 (f2981ec0) (00000001) fw multik misc proto forwarding
        7: - 1fffff2 (f1865ef0) (00000003) vpn tagging inbound (tagging)
        8: - 1fffff0 (f183b250) (00000003) vpn decrypt verify (vpn_ver)
        9: - 1000000 (f29c9c40) (00000003) SecureXL conn sync (secxl_sync)
        10:         0 (f28f4810) (00000001) fw VM inbound  (fw)
        11:         1 (f296bbc0) (00000002) wire VM inbound  (wire_vm)
        12:        10 (f2908b70) (00000001) fw accounting inbound (acct)
        13:   2000000 (f183c6e0) (00000003) vpn policy inbound (vpn_pol)
        14:  10000000 (f29c7f30) (00000003) SecureXL inbound (secxl)
        15:  7f600000 (f293fba0) (00000001) fw SCV inbound (scv)
        16:  7f730000 (f2ad8920) (00000001) passive streaming (in) (pass_str)
        17:  7f750000 (f2cd1320) (00000001) TCP streaming (in) (cpas)
        18:  7f800000 (f294a8c0) (ffffffff) IP Options Restore (in) (ipopt_res)
        19:  7fb00000 (f3072500) (00000001) HA Forwarding (ha_for)
out chain (19):
        0: -7f800000 (f294a520) (ffffffff) IP Options Strip (out) (ipopt_strip)
        1: -78000000 (f1857ff0) (00000003) vpn multik forward out
        2: - 1ffffff (f183ab10) (00000003) vpn nat outbound (vpn_nat)
        3: - 1fffff0 (f2cd11a0) (00000001) TCP streaming (out) (cpas)
        4: - 1ffff50 (f2ad8920) (00000001) passive streaming (out) (pass_str)
        5: - 1ff0000 (f1865ef0) (00000003) vpn tagging outbound (tagging)
        6: - 1f00000 (f294bcd0) (00000001) Stateless verifications (out) (asm)
        7: -     1ff (f2ee26a0) (00000001) NAC Packet Outbound (nac_tag)
        8:         0 (f28f4810) (00000001) fw VM outbound (fw)
        9:         1 (f296bbc0) (00000002) wire VM outbound  (wire_vm)
        10:   2000000 (f183ad30) (00000003) vpn policy outbound (vpn_pol)
        11:   3000000 (f2a9d390) (00000001) ISP redundancy outbound (isps)
        12:  10000000 (f29c7f30) (00000003) SecureXL outbound (secxl)
        13:  1ffffff0 (f18498b0) (00000001) l2tp outbound (l2tp)
        14:  20000000 (f183e6b0) (00000003) vpn encrypt (vpn)
        15:  60000000 (f18505b0) (00000001) tcpt outbound (tcp_tun)
        16:  7f000000 (f2908b70) (00000001) fw accounting outbound (acct)
        17:  7f700000 (f2cd3770) (00000001) TCP streaming post VM (cpas)
        18:  7f800000 (f294a8c0) (ffffffff) IP Options Restore (out) (ipopt_res)

Hope it will help you.

Houssameddine_1
Collaborator

Vezzoso,

Office mode network is unique and it lives in the firewall kernel of checkpoint firewall. Petr is right you have to configure a static route to point to the ISP router next hop and redistribute it to BGP (BGP you can't adverstise route doesn't exist in the routing table). I don't advise you to use the loopback  you might affect tunnel test packets and the client will disconnect.

Another solution, if you have a router behind the firewall create a static route on the router for office mode and the next hop will be the Firewall and redistribute that route.

Could you please describe your topology for better understand the need to redistribute the static route?

Thanks

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    Tue 23 Apr 2024 @ 11:00 AM (EDT)

    East US: What's New in R82

    Thu 25 Apr 2024 @ 11:00 AM (SGT)

    APAC: CPX 2024 Recap

    Tue 30 Apr 2024 @ 03:00 PM (CDT)

    EMEA: CPX 2024 Recap

    Thu 02 May 2024 @ 11:00 AM (SGT)

    APAC: What's new in R82

    Tue 23 Apr 2024 @ 11:00 AM (EDT)

    East US: What's New in R82

    Thu 25 Apr 2024 @ 11:00 AM (SGT)

    APAC: CPX 2024 Recap

    Tue 30 Apr 2024 @ 03:00 PM (CDT)

    EMEA: CPX 2024 Recap

    Thu 02 May 2024 @ 11:00 AM (SGT)

    APAC: What's new in R82
    CheckMates Events