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

How To Get My App Working: Steps To Take

I would guess you need to configure the HTTP Proxy and / or the client apps properly... I find that's the answer most of the time.
It's the "properly" bit that's the hard part.  From the documentation I've seen, there's no definition for how to do it properly.  If an administrator has internalized how all of this stuff is supposed to work with respect to networking in general, and how it works with Astaro in particular, then maybe "properly" is sufficient.  But based on the struggling I see, there's a lot of admins that don't have it all figured out!

Since the thread is for learners, let's presume that the install was done with the installation wizard, and the system has not strayed too far from that initial state.  Certainly the basics are in place, but an HTTP Proxy is in effect (I think that's common).

1) Packet Filter Rules:
The first step I have seen offered is to open the packet filter live log (Logging > View log files > Packet Filter > live log), then try your application.  If you see entries of [DROP], you need to create a rule (Network Security > Packet filter > New rule...). 

2) Content Filter Rules:
Another step I have seen offered is to open the content filter live log (Logging > View log files > Content Filter (HTTP) > live log), then try your application.  If you see entries of [action="block"], you need to adjust your content filter (Web Security > HTTP > Content Filter).

The problem comes with specifically what to do next when these steps have been taken (there are no "DROP" or "block" notices), yet the application still doesn't work.  I have had several game and video sites where I have undertaken steps 1) and 2), but the applications still do not work.

3) Wide-Open Packet Filter with Logging
This technique, offered by RFCat_vk, will enable you to see more about what your application is doing when it works.  The idea is to give it an easy time, temporarily, then use what you learn to do the proper configuration.  First, create a packet filter rule with logging that allows all traffic (Network > Security > Packet Filter > New rule ... > Group: No Group, Position: Top, Source: Any, Service: Any, Destination: Any, Action: Allow, Log Traffic: checked > Save).  Now open the live log for the packet filter (Logging > View log files > Packet filter > Live Log).  Next go to your browser and reconfigure so that it no longer uses the HTTP Proxy, then hit the web site that's been giving you trouble (hopefully this will work for you).  You now should see lots of stuff in the live log that you can use to see what your web page is actually trying to do.  By the way, if you can't silence the rest of the network, it might be wise to create your packet filter as "Source:" then drop in just your test machine.  When you are done, you will want to remove the test packet filter rule, of course.

4) Turn off Intrusion Protection
This will be enabled by default after the installation wizard.  You might not want to leave it disabled, but you could try disabling it, then try your failing web site.  To disable, you go to Network Security > Intrusion Protection > Global > Disable.  IPS Status will turn red.


I would hope this thread gets more ideas for how to continue to "dig" and how to make additional adjustments to get applications working through the gateway, as well as specific questions for applications tried, observations, successes and failures.

--Dale--


This thread was automatically locked due to age.
  • Hi Dale,
    take a step back. Disable the proxy. Create a packet filter rule
    internal -> any (port) -> any network -> allow. If your application works with this setup , then turn on logging to see what other packets/ports/ destination addresses are required.

    Ian M
  • Hi Sengsational:

    Thanks for the good info...

    I've tried all those myself and I've had no luck at all... The two apps I've had the big issues with are Ventrilo (voice chat) and Rise of Nations (video game).

    Both work just find without ASG, but when I try to go through ASG no connections can be made.

    Nothing in the log files, even tried making the any,any,any solution, and that was a no go. 

    I really do not understand DNAT/SNAT so I haven't played with those yet. I will try to find a good example of how those work and maybe those will fix my problems.
  • take a step back. Disable the proxy. Create a packet filter rule internal -> any (port) -> any network -> allow. If your application works with this setup , then turn on logging to see what other packets/ports/ destination addresses are required.
    Thanks for the idea.  I shall try this trick and report back.
  • Create a packet filter rule
    internal -> any (port) -> any network -> allow. If your application works with this setup , then turn on logging to see what other packets/ports/ destination addresses are required.
    Ian, When I did the full allow thing, the application worked.  Here's what I came up with...

    I looked at the packet filter log and the source machine had a bunch of TCP entries from ports ranging from 1349 to 1550.  The destination ports were all port 80:

    198.105.193.243 : 80 [ACKPSH ]
    68.142.118.103 : 80 [SYN]
    64.154.81.197 : 80 [ACK]
    68.142.111.16 : 80 [ACKPSH ]
    198.105.193.11 : 80 [ACKPSH ]
    198.105.194.76 : 80 [ACKPSH ]
    72.247.241.50 : 80 [SYN]
    198.105.194.76 : 80 [SYN]
    8.14.56.49 : 80 [ACKPSH ]
    72.32.97.235 : 80 [SYN]
    69.28.159.142 : 80 [SYN]
    68.142.111.16 : 80 [SYN]
    72.32.97.235 : 80 [ACKFIN ]
    209.85.163.91 : 80 [SYN]

    (removed the duplicate entries).

    What this tells me, since it's only going to port 80, is that it should work through the proxy as well.  But it doesn't.  Is that a proper conclusion?

    Any more ideas for digging?

    --Dale--
  • I added turning off IPS as another diagnostic trick to post #1
  • Hi Dale,
    I am not sure that the http proxy can handle strange returned addresses. You will need to create a group of addresses and add that to the destinations in the http proxy. You might also need to add some allowed ports into the proxy eg a group range for those ports in the PF log. It is a possibility that the application uses those ports natively, but I doubt it.

    Ian M
  • I am not sure that the http proxy can handle strange returned addresses.
    Thanks for the reply Ian.  It wasn't clear from the little bit I posted, but when I hit the "problem" web page, the logs showed my machine going to all of those port 80 destinations (a bunch of ad servers, I bet).  Since I initiated the conversations, there should be no problem hearing back from those sites, yet it doesn't seem to make it through the proxy.

    On another thread, I saw someone mention "the proxy bug" (as if we all had heard of it).  Have you?

    --Dale--
  • Wireshark is also a great tool to figure out whats happening on your network. 
    Mirror the switch port for your gateway to the port that the sniffer's on. Combined with the packet filter logs, this will tell you about everything you want to know.

    If you don't want to mess around with port mirroring on your switches and all that junk, then just put it on the machine you're trying to test. It will at least tell you what SYN's aren't getting ACK's...
  • Hi Dale,
    I don't know about the proxy problem, but that doesn't mean much. I have a similar issue with dropped packets and started threads on the subject, but thought it was just a failure in the logging software not to report on all the connections.
    My ASG doesn't log all the connecting traffic even with the log box ticked. I didn't get an responses to my threads so I assumed it was something I was doing wrong in my configuration. Another thread indicated that there is/was a problem with a driver for one of the realtek chip NICs, so I replaced them all with intel chip NICs, but no real improvement in the dropped or logged packet information.
    I will give wireshark a go when I return home.

    Otherwise I don't know where to go from there.

    Ian M
  • Wireshark is also a great tool to figure out whats happening on your network. 
    Mirror the switch port for your gateway to the port that the sniffer's on. Combined with the packet filter logs, this will tell you about everything you want to know.

    If you don't want to mess around with port mirroring on your switches and all that junk, then just put it on the machine you're trying to test. It will at least tell you what SYN's aren't getting ACK's...


    For sniffing external traffic, or both sides of the firewall, you can run TCPDump on Astaro, dump to a file, SCP the file to a PC and load into WireShark.

    Or, if it's simple enough, just read the TCPDump output on Astaro.

    Would be really nice if there was a way to get TShark running on ASL.

    Barry