Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 14 replies
  • Answers 1 answer
  • Subscribers 28 subscribers
  • Views 2947 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Site-to-Site RED (XG to XG) unable to pass DHCP / connect to remote bridged devices

Greg Williams

Goal:

Create a single network between two remote locations accomplished by using two Sophos XG firewalls setup with RED connections using same subnet.

 

Requirements:

The restrictions of the of underlying devices (a DVR and cable Set-top-boxes) on this network require they all be on the same subnet and be able to freely pass/receive any broadcast messages across the subnet so as to discover and communicate with each other.  This needs to occur across the local and remote locations.

 

Problem:

Simply put I have been unable to figure out how to successfully configure a seamless subnetwork where data and any broadcasted data is passed between the local and remote boxes. Known here out as box 1 and box 2

Here is the current setup:

SFXGBox 1 – Verizon

XG Version – 17.5.10 MR-10

Port 1 – 192.168.1.x
Port 2 – Verizon (WAN)
_________________________

Bridge (Br0) – 192.168.100.103 (DHCP setup to serve requests on interface Br0)
     Bridged Interfaces:

  • Port 3 (Physical port)
    • DVR – 192.168.100.112 – (DHCP successful)
    • STB1 – 192.168.100.113 – (DHCP successful)
  • reds1 – Firewall Red Server (online Spectrum IP displayed)

 

SFXGBox 2 – Spectrum

XG Version – 17.5.10 MR-10

Port 1 – 192.168.3.x
Port 2 – Spectrum (WAN)
_________________________

Bridge (Br1) – 192.168.100.115 (received DHCP from Box 1)
     Bridged Interfaces:

  • Port 3 (Physical port)
    • STB2 – 192.168.100.xxx (unable to get DHCP from Box 1)
    • Test PC – 192.168.100.xxx (unable to get DHCP from Box 1)
  • reds1 – Firewall Red Client (online Verizon IP displayed)

 

BOTH XG BOXES HAVE FIREWALL RULES TO ALLOW LAN TO LAN TRAFFIC ANY SERVICES

 

More Info:

Each XG firewall has two independent networks defined under Port 1 on Box 1 & 2, (192.168.1.x & 192.168.3.x respectively) these are self-contained and are currently operating independent of each other and working as designed / expected – No changes needed or wanted here.

The common network I am attempting to create (192.168.100.x) between the two Sophos XG boxes is utilizing a RED site to site tunnel.  I have successfully created the tunnel on each box (using Red Server / Red Client method) and they both show online; displaying the others WAN IP.  

On Box 1, I have bridged the physical Port 3 and the reds1 (setup as RED SERVER) interfaces to create interface Br0 (both Port 3 and reds1 are in LAN zone) then set the static network as 192.168.100.103 /24, I have also selected “Enable routing on this bridge pair”.

On Box 1, I have setup a DHCP to serve requests on interface Br0 - 192.168.100.103 (to supply IP range 192.168.100.111 – 192.168.100.199 / 24) with DNS as 192.168.100.103

On Box 1, I have connected an external switch to Port 3 (Br0) and plugged in both my DVR and STB.  Both devices successfully obtained an IP from the DCHP on Box 1, have internet access, and are both able to communicate with each other.

Here begins my problem

On Box 2, sticking with the same methodology, I have bridged Port 3 and reds1 (setup as RED CLIENT) interfaces to create interface Br1. (both Port 3 and reds1 are in LAN zone). Here instead of static network I choose DHCP, I have also selected “Enable routing on this bridge pair”.

On Box 2, the new bridge successfully receives an IP from DHCP on Box 1 and set as 192.168.100.115. (So here I can tell I have some communication between the two boxes but that is where it ends).  I added another switch to physical Port 3 on box 2 and connected both the 2nd STB as well as a TEST PC to ensure the connection was working. Ignoring the 2nd STB at this point I’ve focused on the TEST PC to ensure I can get the basic network to function.

On Box 2, I attempted to pull an IP from the TEST PC connected to Port 3 on its bridged interface, I assumed it would work.  I assumed wrong. I am getting no response from the DHCP on box 1. 

Apart from playing around with different combinations of settings (completely stabbing in the dark). I seeking any assistance in how to get this setup to work.  Maybe I’m on the right track or completely off course? 

Noting: I have successfully followed the Sophos directions on how to setup an XG to XG RED but it was more aimed at connecting two different subnet. Which is not exactly what is needed here.

I am including a diagram of my current setup.  The bit in the green box is what I am trying to create.  The bit in the red box is the part that does not work.



This thread was automatically locked due to age.
Parents
  • 0

    I did the same in V18, without any Problems - So it is working. 

     

    You should do following: 

    Go to the CLI - Perform Tcpdumps on the Bridge and the Interfaces to verify, where the root cause is sitting.

     

    You can perform a tcpdump: 

    tcpdump -ni PORT port 67 or port 68 

    tcpdump -ni PORT arp 

     

    You should start with the first command and check the Ports. First of all, check the Bridge Interface (br0).

    Second check the single Interfaces to nail down, where the issue is sitting and which box is not relaying the DHCP. 

     

  • 0 in reply to LuCar Toni

    @LuCar Toni,

    Thanks for the reply.

    I ran the tcpdump on both boxes simultaneously and then logged onto my Windows 10 Test PC connected to Box 2 on the bridged Port 3. As soon as I hit enter for the IPCONFIG /renew, both Box 1 and Box 2 began immediately responding.

    From what I'm interrupting it appears the DHCP is responding with an IP (192.168.100.114) and is also being received by the 2nd box, I recognize the requesting MAC address as that of the Windows 10 TEST PC, but the TEST PC is still not picking up the address.  Or perhaps I am misinterpreting the results. I've attached screen shots what I have received.

    Additionally, as suggested on the Box 2,  I also ran the tcpdump on both the interfaces and both are responding similarly as shown below.

    Any other thoughts?

     

    TEST PC

    BOX 1 (DHCP SERVER) (Br0)

     

    BOX 2  (Br1)

  • 0 in reply to Greg Williams

    Box2 seems to not forward the Request. But actually it is weird, that you do not see the Packets outgoing. 

    Are you sure, there is no direct link? 

     

    Because actually what you should see: 

     

    Box2: DHCP Request IN 

    Box2: DHCP Request OUT 

    Box1: DHCP Request IN 

    Box1: DHCP Reply Out

    Box2: DHCP Reply IN

    Box2: DHCP Reply OUT 

     

    It is odd, that you only see Incoming packets on Box2. 

    Box1 seems to be fine. 

    Why are you using br1? 

  • 0 in reply to LuCar Toni

     

    Totally missed that,

    I am using br1 on box 2 as the bridge between the RED and Port 3 with the hopes to pass / forward along the DHCP and all other traffic between to the other devices attached to PORT 3. Essentially I was trying to keep the network together as one subnet across both boxes.  I would not argue if my thought process or understanding of the proper use of the bridge here is flawed, but this was best logical thought I could come up with. 

    To be honest,  I'm not sure if this is the correct route to take or not.  The server side setup I felt comfortable with, its the client side on the XG box that I really could not find good documentation on (with relation to the use of a 2nd XG firewall). 

    I'd really like your input if you think this is the best route or if there is a more efficient alternative I haven't considered yet, or perhaps I'm almost there but missing a step?

    The network diagram I originally posted is what I need to achieve (the setup in the green box)

    Thanks for your input thus far,  I truly appreciate it.

  • 0 in reply to Greg Williams

    It is actually the correct setup. Looks like Box2 feels not to be responsible to forward those packets. 

    Maybe you are up to something. 

    Your are saying, Box2 has a Dynamic IP? Is this Dynamic IP working? Could you change the XG Box2 IP to Static and redo the Dumps? 

    Also please craft Dumps on the Interface Level (replace br0/br1 with the actual Interface names). And please create the interfaces on Advanced Shell (Option 5 / 3). 

Reply
  • 0 in reply to Greg Williams

    It is actually the correct setup. Looks like Box2 feels not to be responsible to forward those packets. 

    Maybe you are up to something. 

    Your are saying, Box2 has a Dynamic IP? Is this Dynamic IP working? Could you change the XG Box2 IP to Static and redo the Dumps? 

    Also please craft Dumps on the Interface Level (replace br0/br1 with the actual Interface names). And please create the interfaces on Advanced Shell (Option 5 / 3). 

Children
  • 0 in reply to LuCar Toni

    Ok I have rerun the tcpdumps on both the individual interfaces on box2 (reds1 and Port3) results are still the same. 

    With regards to the if DHCP is working.  Yes, I had DHCP turn on, the box2 bridge interface (br1) was successfully receiving an IP from box 1.  As suggested I have set a static IP and have rerun the tcpdumps (screen shots below)

    I'm not very strong with the CLI interface so I was unable to recreate the interfaces as such.  However, to rule out any current mis-configurations in general I have done a clean install of version 18 (on box 2 only) and re-established the RED connection.  The test results below are on the refreshed install. 

    I'm starting to think that I am missing possibly a static route setup or firewall rules?  presently I have no routes established and besides the default NAT'd LAN to WAN rule,  I have only created a LAN to LAN rule so the RED and LAN can communicate.  Thoughts on this? or do you still feel this is something else?  I've included screenshots of box2's setup for reference.

     

     

     

  • 0 in reply to Greg Williams

    Basically the Advanced shell uses commands like:

    tcpdump -ni Interface_Name port 67 or port 68 

    It is quite easy and this command is public (tcpdump is a public used opensource tool. You will find many resources about this on in the internet). 

     

    It looks like, the other appliance is not responding / forwarding. 

    Could you show us the other appliance settings and tcpdump? 

  • 0 in reply to LuCar Toni

    Ok, just want to ensure we are on same page.  The screen shots in the previous post were the settings for box2 (reposting below), along with the tcpdumps showing box1 and box 2 (identified by their IPs shown in the admin URLs 192.168.100.103 (box1) & 172.16.16.16 (box2)  I thought we already identified that it is box 2 that is not responding forwarding?  

    When reviewing the tcpdumps, I can see that that box1 is responding with IP assignment 192.168.100.170 and box2 is also receiving same, but not forwarding to the underlying requesting device.

     

    Box 1 Settings

     

    Box 2 Settings

     

  • 0 in reply to Greg Williams

    In your last post, the screenshots of the Dump looks fine right now tbh. 

    This is the Screenshot of your Interface with your Client. 

    https://community.sophos.com/cfs-file/__key/communityserver-discussions-components-files/126/Box2-TCPDUMP-Port3-R2.PNG

     

    Client "should" receive a DHCP Reply and pick up. 

    Somehow, he does not. 

    Could you please create a Wireshark Dump on the Client? 

    There could be two reason: 1. The Reply does not reach the client (can be verified in Wireshark). 2. The Client does not want the reply of the Client for what ever reason. 

  • 0 in reply to LuCar Toni

    Wireshark is an interesting utility.  I have attached the Wireshark capture in the zip file below along with a simultaneous tcpdump on box 2

    So it looks like data is getting dropped at Port 3,  as the client test pc is not receiving a response.

    Also as an additional observation, since technically I know the expected results I want to return from the DHCP,  I manually assigned the IP / Gateway / & DNS servers on the test PC and I receive no connectivity,  it looks like data is still being dropped between Port 3 and the underlying devices. 

    As always, I appreciate your insights

     

    wdump.zip

     

  • 0 in reply to Greg Williams

    I am very sure, something went wrong between Port3 and your Client. 

     

    Tcpdump on Port level is actually the packet leaving the interface. Therefore this packet actually left Port3. But it does not hit the Client. 

    If you investigate the communication path between Port3 and your Client, can you see something blocking or rerouting the traffic? 

  • 0 in reply to LuCar Toni

    Just wanted to share, that I was finally able to figure this out and I have it working correctly!

    Apparently, I hadn't found it necessary to share that I run Sophos in a virtualized environment as I have never run into any problems with the operation and expected results of Sophos(until now).

    So all this maddening mess was caused by a simple check box in Hyper-V under the network settings to Enable MAC address spoofing.  After I had checked the box and re-launched the Sophos virtual machine, everything lit up like a Christmas tree and began working. SMH.   I can't believe something so innocuous could cause such a headache!

    Thank you again for all your suggestions appreciate all the support you provided.

  • 0 in reply to Greg Williams

    Hi,

    I have the same configuration on my BO and HQ...

     

    But, when the BO device goes on Internet use the BO connection (public IP)

    How can I set to goes on Internet by HQ connection?

     

    Thanks

  • 0 in reply to cyberguy

    Hi cyberguy,

    If I'm understanding your question correctly, you are experiencing all internet traffic from your BO being routed out through the BO's ISP instead of being routed through your RED site-to-site and then ultimately out through your HQ ISP connection.

    If so, this can be remediated fairly quickly. Unfortunately, you've not provided much detail to go off of so this guidance will be bereft and based on assumption. 

    Assuming you've created a separate ZONE for the RED Site-to-Site on both the client and server(If not, I'd recommend to do so).

    You should simply need to configure firewall rules on both the client and server side as follows.

    • On your client side create an outbound rule to set Source and Destination zones to match the ZONE you created and setup for your RED client,  Source networks, destination networks, & services should be populated with ANY
    • One your server side locate and edit your rule that allows HQ internet traffic to pass externally(or create a new one).  In your Source Zones, add the ZONE you setup for your red connection and save.

    All BO traffic will now be routed through the RED site-to-site connection, subsequently all internet traffic will pass out though your HQ ISP (BO & HQ)

    Obviously, this is a the quick and dirty way to obtain your goal and likely many other best practices exist.  Hopefully this gives some guidance or ideas on your specific situation.