Guest User!

You are not Sophos Staff.

Thread Info
  • Locked Locked
  • Replies 11 replies
  • Subscribers 27 subscribers
  • Views 17045 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

So Close but no cigar

B.R.O.

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.
Parents

  • BRO,

    changing a Firewall is always a big challenge and the challenge become harder if you do not know really well the network you are managing, what the configuration are, the firewall you are coming from and the one you are going to. This is a terrible mix.

    I am sure you will find the solution.

    Thanks for sharing your experience. (To mention someone, use "@" before the name. A drop-down menu will appear).

    Regards

  • in reply to lferrara

    This may be the problem, the interface stayed open with the old firewall, the xg in transparent mode kept closing it, bypass stateful traffic corrected that. 

    Issue:

    When attempting to start instrument interfaces, despite correct application 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 Park Place (or another 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.
  • in reply to B.R.O.

    They also have a router behind the firewall.  I will assign the router to the dmz.

     

    Firewalls
    ---------
    If the router is behind a firewall there are some important things to note. The company connects using TCP/IP and UDP mainly. Port assignments are random as generated by Windows, however those connections will always be initiated on port 2989 and are above the well known ports (>1024).

    The company utilizes a proprietary piece of software, called CS Connect, as a support mechanism. This piece of software works in such a manner that once the initial connection is made from the company to the server on-site, the server will then source the connection back to the company. This is important to note, as it will be necessary to allow the source connections to come back out the firewall.

  • in reply to B.R.O.

    Hi BRO ,

    Any chance you have created a Plain Rule ?

  • in reply to Aditya Patel

    I guess not,  on my last attempt to install the firewall all I noticed was that by the time I rebooted the xyplex terminal servers and restarting the lab interfaces they would not open.

  • in reply to Aditya Patel

    The Xyplex terminal servers also have a ip route using a server in the datacenter and the virutal router as the gateway!  I am analyzing them now to see what I am missing...

  • in reply to B.R.O.

    HI BRO ,

    Sure , let is know your findings .

  • in reply to Aditya Patel
    This reply was deleted.
  • in reply to B.R.O.

    this is what I am seeing on my test

     

    Local ACL  -   Denied -   Firewall Rule 0 - 10.141.12.5:UDP (2001)  to 255.255.2555.255:UDP (37)

     

     

    While doing a continous ping (ping 10.141.12.5 -t) this is all the firewall logged after at least 100 pings...

     

     

    XG310_WP01_SFOS 16.05.3 MR-3# tcpdump -nei any host 10.141.12.5
    tcpdump: Starting Packet Dump
    05:08:21.611416 Port1, IN: B 08:00:87:0c:a0:79 ethertype IPv4 (0x0800), length 62: 10.141.12.5.2001 > 255.255.255.255.37: UDP, length 0
    05:09:21.612518 Port1, IN: B 08:00:87:0c:a0:79 ethertype IPv4 (0x0800), length 62: 10.141.12.5.2001 > 255.255.255.255.37: UDP, length 0
    05:10:21.654663 Port1, IN: B 08:00:87:0c:a0:79 ethertype IPv4 (0x0800), length 62: 10.141.12.5.2001 > 255.255.255.255.37: UDP, length 0
    05:11:21.611373 Port1, IN: B 08:00:87:0c:a0:79 ethertype IPv4 (0x0800), length 62: 10.141.12.5.2001 > 255.255.255.255.37: UDP, length 0
    05:12:21.609265 Port1, IN: B 08:00:87:0c:a0:79 ethertype IPv4 (0x0800), length 62: 10.141.12.5.2001 > 255.255.255.255.37: UDP, length 0
    05:13:21.610227 Port1, IN: B 08:00:87:0c:a0:79 ethertype IPv4 (0x0800), length 62: 10.141.12.5.2001 > 255.255.255.255.37: UDP, length 0
    05:14:21.607982 Port1, IN: B 08:00:87:0c:a0:79 ethertype IPv4 (0x0800), length 62: 10.141.12.5.2001 > 255.255.255.255.37: UDP, length 0
    05:15:21.654231 Port1, IN: B 08:00:87:0c:a0:79 ethertype IPv4 (0x0800), length 62: 10.141.12.5.2001 > 255.255.255.255.37: UDP, length 0
    05:16:21.606834 Port1, IN: B 08:00:87:0c:a0:79 ethertype IPv4 (0x0800), length 62: 10.141.12.5.2001 > 255.255.255.255.37: UDP, length 0
    05:17:21.607922 Port1, IN: B 08:00:87:0c:a0:79 ethertype IPv4 (0x0800), length 62: 10.141.12.5.2001 > 255.255.255.255.37: UDP, length 0
    05:18:21.605673 Port1, IN: B 08:00:87:0c:a0:79 ethertype IPv4 (0x0800), length 62: 10.141.12.5.2001 > 255.255.255.255.37: UDP, length 0

  • in reply to B.R.O.

    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.
Reply
  • in reply to B.R.O.

    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.
Children
No Data