Guest User!

You are not Sophos Staff.

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

So Close but no cigar

My latest attempt to install the XG Firewall in a extreme sleep deprivated mind...

Everything was working up here at the hospital except for the lab machines.

One such device have a NATed Ip 172.16.176.46 that connects to a xyplex terminal server with ip address 10.141.12.6

 

1.  first failed attempt to install the firewall 3 months ago was lack up understanding the Datacenter's layer 3 routers in my network

2.  2nd failed attempt nothing worked and I only had 5 minutes to diagnose before putting the old firewall back up

3.  third attempt - well I was stumped so I configured the HA failover unit as a transparent bridge binding most of the interfaces together

     a.  lab interfaces worked but timed out, my work around was to vpn in my network every 2 hours to use putty client to reboot the xyplex terminal servers and got stuff

          done.

4.  captured this packet screen shot here...

 

The terminator lferrara advised I read this article carefully:

https://kb.cyberoam.com/print.asp?id=2017

That explains asymmetric routing...

this is what I did to the XG after reading the article

I entered all my networks to bypass stateful traffic like this...

Source - Destination

8.8.8.8   255.255.254.0        2.2.2.2     255.255.255.0

8.8.8.8   255.255.254.0        3.3.3.3     255.255.255.0

8.8.8.8   255.255.254.0        4.4.4.4     255.255.255.0

2.2.2.2     255.255.255.0       8.8.8.8    255.255.254.0

3.3.3.3     255.255.255.0       8.8.8.8    255.255.254.0

4.4.4.4     255.255.255.0       8.8.8.8    255.255.254.0

 

Violia!!! lab had no worries and I didn't have to restart those terminal servers all the time.

 

5.  activate email trial and had email working (trial ends today)

6.  After careful review and I did enter the bypass stateful rules to be more reflexive

I entered them in the newer firewall like this

8.8.8.8   255.255.254.0        2.2.2.2     255.255.255.0

2.2.2.2     255.255.255.0       8.8.8.8    255.255.254.0

8.8.8.8   255.255.254.0        3.3.3.3     255.255.255.0

3.3.3.3     255.255.255.0       8.8.8.8    255.255.254.0

8.8.8.8   255.255.254.0        4.4.4.4     255.255.255.0

4.4.4.4     255.255.255.0       8.8.8.8    255.255.254.0

 

no problems with anything except those lab interfaces when installing the xg firewall again.

 

Now the lab was working when I had the xg in transparent bridge mode between the core switchy(layer 2) and the router

I moved a any all to any who firewall rule to the top of the food chain, like all traffic should see it and scream woo-woo!

labs still didnt work

Sonicwall must have has a port opened for this to work on their firewall,  once the sonicwall was gone the lab ran into the same problems as before

zzzzzzz.... taking xg home and letting support access it to look at it.

soooooooo closeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee!

 

4.4.4.4     255.255.255.0       8.8.8.8    255.255.254.0



This thread was automatically locked due to age.
  • Instrument Connectivity Issues with XYZ and Other Hosts

    Issue:

    When attempting to start instrument interfaces, despite correct program setup, the interfaces will not start, often getting stuck in a "Starting" status.

    Resolution: 

    Often times, with hosts in general, connections between machines will be closed due to security protocol. Sometimes the connection between the background client running LAB analyzer background jobs and the term server is closed. Specialists may use the Process All Background Jobs routine to determine the BKG client running the analyzer jobs. Specialists can then check the LIS Device Dictionary to determine the IP address of the term server(s) being used. Once the host is aware of the issue, they are able to adjust the access settings to the firewall, allowing for the necessary connectivity. Starting of interfaces and testing of transmissions will confirm the connectivity.

    Other Considerations:

    Keep in mind that LIVE and TEST will typically have different BKG clients running the analyzer background jobs. Site's host will need to be made aware of this. Often times the BKG machine running background jobs in TEST will be changed once the LIVE environment is created. Please ensure that both background clients have access to the IP adress of the term server(s) being used.