Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 13 replies
  • Subscribers 2 subscribers
  • Views 2967 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

Possible NAT/IPS issue?

Jayson
Howdy All:

I'm having a bit of an issue getting programs like Ventrilo (voice over ip chat) and video games etc to play through the ASG.

I have setup Packet Filter Rules which is what I have done for other programs and those seem to work just fine, EVE, WOW (both games), Email, Google Chat etc... the list goes on of working rules/programs.

Nothing is showing up in the packet filter log or the IPS log. I would expect to see a dropped packet or something, but nothing for the ip addresses I'm trying to get to.

An examle would be: My ventrilo client ---> to friends ventrilo server.

Other people are able to connect just fine. If I take ASG out of the picture and run directly I can connect as well. 

I'm running one Masquerading rule: Internal --> External (which was made during install)
I'm running 15 packet filtering rules: I have moved the rule thats not working up and down the list to make sure another rule is not cancelling it out.

I know thats limited information, but maybe someone else has had the same issues and knows what I'm talking about?

Edit:

I should mention as well, if I turn off the rule Ive made for ventrilo I will then see the UDP packets being dropped on the packet filter log...


This thread was automatically locked due to age.
  • 0 in reply to ClausP
    I have no DNAT rules... The one above was for testing only. The only NAT rule I currently have is the default internal -> external
  • 0 in reply to Jayson
    you have a pm ! [;)]
  • 0 in reply to Jayson
     I was still not getting any dropped packets on the live log. 
    I just came across this thread and I think that the real problem is that when the gateway takes negative action with things, it's not always reported.  I can't see how one would be able to fix problems without diagnostic information!  Going to the vendor doc is not workable most times.  What you did with netstat is workable, but it's just a poor indication of what the gateway is actually seeing and doing.

    There needs to be a "power blocked log" that you can turn on when something doesn't work.  It should spit-out every negative (blocking) action that the gateway took, from any and all subsystems.  You turn it on, try your application, turn it off, and dig into it.  There should be nothing dropped that isn't represented.  Yes, you will need to be smart enough ignore the IBR (internet background radiation) that has nothing to do with your test, but if everything dropped is noted, there will be no guesswork; there seems to be a lot of that required to get things working as it stands today.

    --Dale--