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.
Parents
  • 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...
Reply
  • 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...
Children
  • 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
  • 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.
    BarryG. I'd like to flesh this out a bit for the novice (i.e. me).

    I don't see a reference to TCPDump in the Admin Guide.  Where do I get the details for how to proceed with the TCPDump?

    --Dale--
  • It's accessible from the console... SSH or use a keyboard and monitor, log in as "loginuser" then "su" up to root... tcpdump -h will tell you all you need to know.