Connecting RED's to XG when using BGP

Hi MichaelBolton 

As per the information provided you want to configure RED device and XG firewall connectivity using BGP, please correct me.

Yes, I want the RED's to connect back to one of the IP's on our /22 public block that will be routed via BGP.

Hi MichaelBolton 

Please allow me some time to check for you, we will inform you further.

Hi MichaelBolton,

Please provide the below information.

1. RED device model number

2. How RED device getting Internet? (To fetch configuration file)

3. Network Diagram to understand the setup

RED device uses below Ports to communicate

RED hardware Ports

RED 10TCP 3400 + UDP 3400

RED 15TCP 3400 + UDP 3410

RED 50TCP 3400 + UDP 3410

The RED devices are at different locations. Some use static IP's, some use DHCP.

I don't really understand the need for a network diagram. It is a very simple setup. A Sophos XG multihomed to 2 ISP's using BGP.

Here is a Cisco doc that has a diagram. This is a very standard setup in enterprise networks.

https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/23675-27.html

So you do not have a WAN Interface only the eBGP Interface? 

Many services relies on the WAN Interface (Interface with Zone WAN). I know, you are not able to configure the WAN Interface, because you are getting all routes from your ISP. 

There is no "Quick and dirty" Solution right now.

As far as i know, you can basically build a Dummy Interface on your XG with zone WAN and use a business application rule (NAT) to route the traffic Port 3400 and Port 3410 to this interface. 

BTW: RED should be open on all ports. Did you check, if you can connect via nmap to port 3410 to your ISP WAN IP? 

Yes, that is correct. BGP doesn't use a WAN interface. I just have a point to point link to each providers edge router.

I will try the dummy interface and see what happens.

All ports are open. The XG is just not listening on those IP's because they are not tied to an interface, just routed. I am guessing all of the services will suffer from this as well. Like SSL VPN, VPN, etc..

There are only IPsec+WAF as a use case issue in this setup. 

IPsec can only use a WAN Interface as SA. 

So you cannot build up a Site to Site in this setup.

RED should be open on all Ports (Port 3400 and 3410).

SSLVPN can be activated on their own Zone (So no binding to WAN). 

With V18, you can actually DNAT /NAT this traffic to another Port to get this up and running again. 

There is no zone. The interface is a point to point link. Our block of IP's are NOT on any interface.

DNAT does not work for SSLVPN. I have not tested the RED service yet.

You must have a Interface in any Case. How should this work otherwise? 

eBGP relies on having any kind of Interface with any kind of IP. 

Its most likely a DMZ Zone interface or a self created Zone. 

Or which IP do you setup on your Interface? A point to Point link to the ISP is still a valid IP on your Interface. So you can actually use this IP on your SSLVPN configuration as overwrite hostname and you can still use this Zone on this Interface to setup SSLVPN. 

Yes, there is a DMZ zone for the PTP link and each interface has an IP assigned by THAT carrier.

The whole point of BGP is carrier redundancy. Why would I want to use a carriers IP for SSLVPN? The whole point is to use OUR IP block for all services. If I use carrier A's PTP IP, if they go down, our users can't connect. That is not a viable solution.

It sounds like to me, XG does not handle BGP properly like other vendors routers and firewalls do.

Yes, there is a DMZ zone for the PTP link and each interface has an IP assigned by THAT carrier.

The whole point of BGP is carrier redundancy. Why would I want to use a carriers IP for SSLVPN? The whole point is to use OUR IP block for all services. If I use carrier A's PTP IP, if they go down, our users can't connect. That is not a viable solution.

It sounds like to me, XG does not handle BGP properly like other vendors routers and firewalls do.

Then use a DNS Record for SSLVPN.

Do not forget, SSLVPN is a point to point connection.

The Client needs a IP to connect to. 

You could actually give the SSLVPN client a DNS record. 

Do you have something in place to get DNS redundancy? 

Redundancy is also being used by Services, and most likely its used by DNS. 

Having said, i do not care, which IPs Google use, i simply connect to google.com. 

So if they failover to another IP, uses other IPs, i simply dont care. I do not notice. 

And you could use DNS for all causes like SSLVPN, like RED etc. 

And you are not using the Carrier IP, you are using your IP, which you get by the carrier. 

I appreciate you trying to help but I don’t think you understand how BGP works.

If I use a DNS record, I’m going to point it to one of my IP addresses. The XG is not listening on those IP’s because they are not terminated to an interface.

Using multiple IP’s on a DNS record is bad practice if the IP’s are not using BGP. You’re suggesting using the carrier’s IP’s which could go down. The clients will have that IP cached.

Google uses multiple IP’s on a DNS record for load balancing. All of those IP’s are advertised via BGP for redundancy.

The IP’s I want to use ARE NOT addresses we get from the carrier. They belong to us. We advertise them to the ISP’s.

Why should your IPs not using BGP?

I am not talking about DNS with multiple IPs. I am talking about services in DNS, which provides health checks. 

Use something like Route53 with keep alive tracking etc on your IPs, which you are pointing to ISP. 

Lets wrap this up.

You are advertising your IPs to the ISP. 

It is generally speaking working for you in case of redudancy. 

You need now a RED working. 

A RED can basically connect to two different Hostnames (main and failover). Those Hostnames could be DNS. 

Same for SSLVPN. You have a Overwrite FQDN. This is copied into the SSLVPN Configuration. 

Using something like Route53, you could easily get your IPs replaced in nearly realtime, if one IP / uplink is down. 

I am still not talking about the carrier IPs. 

The whole point of BGP is to not use a 3rd party service like Route53.

Lets discuss, why XG is not acting properly in your scenario.

How should XG react in case of Interface lose for RED? 

The RED cannot connect to any of the IP addresses in our block.

If it could, lets say 205.12.34.123, if the peering went down with one ISP, the other ISP would have the route to that address. It is the basics of BGP. I am not understanding why you can't understand how BGP works.

I need the XG to respond to services on a BGP address block. It is as simple as that. I cannot use an address on the PTP link with either ISP.

Still not clear.

Why should the RED not be able to connect to your IP? 

Your IP 205.12.34.123 is reachable via BGP and is a IP based on your XG (One of your Interfaces). 

If this IP went down, the Interface still holds this IP - So basically the IP is still reachable via other route to your XG.

Why should those Packets from RED not reach the XG? 

You said, you are not getting any IP assigned by ISP, instead you are holding your own IPs and simply publishing your routes to ISP via BGP. 

So basically your IPs are static? So because of link local loop back interfaces, the XG will respond always to your static IPs. 

No, in this example, 205.12.34.123 is an IP in our BGP block. Not on an interface on the XG. That is the whole problem.

So you do not hold own IPs? 

Are those leased IPs, which you are allowed to publish through BGP? 

What are you using exactly? 

But nevertheless, still the fact: 

You are getting a block of IPs, As said, RED supports only two different IPs as hostname. 

So ether use two of those IPs in your block or use a DNS service. 

Please listen to what I am saying. We have our own block of IP's. A /22 block.

We advertise those to 2 different ISP's using BGP.

The /22 block is NOT on any interface on the XG. The only interfaces are 2 DMZ interfaces that have /30 IP's for the PTP links to the carriers provider edge routers.

How can we get the XG to listen to services (RED, SSLVPN, IPSEC VPN, etc,) on any IP out of the /22 block?