OK, I have not worked with the Version 8.x much, have been stuck on the old version 7.x
but here goes.
I have some applications I have to let through the new MFE but are not listed in the Applications, and do not find anything close to what I need, Thus I create a new custom application and select TCP/UDP, put in the TCP port, I need it to allow through.
THen create my Access Control Rule and select the new application I just created. The multiple source host on the internal zone and end points on the external zone and finish out the rest of the basic config.
Now when watching the audit, I see it show up as a TCP net probe, from my selected host, to the proper destination host and on the port it is supposed to be on. with a reason of
Received a TCP connection attempt destined for a service that the current policy does not support.
Any suggestions or help that anyone can recommend. As I have several of these custom applications that I must get working.
What is the dest_zone in the audit message?
Do a 'route -n get [dest. IP]' on the firewall to make sure the destination IP is routed out the correct interface (and thus zone).
The process you explain is essentially correct. For "Proxy" in version 6, think "Service" in version 7, and "Application" in version 8.
If you wish to create a custom "application" definition you do exactly what you say, create a new entry, select the TCP/UDP radio button and specify the required ports (assuming it it TCP or UDP-based).
When you save this entry and look at it in the application list you will see that it is referred to as an "Infrastructure Service".
If you need to work with multiple services you can create an application group, but as v8 now allows multiple applications, sources and destinations to be added individually to a rule it isn't quite so important to do so.
Then you create your rule. Like version 7 as soon as a rule has been created the underlying process (daemond, I think) should then start a listener service in anticipation of traffic on that port. Sam (sliedl) will be able to confirm, but I think the exception to this is if the rule has an application defense assigned that switches behaviour into basic packet filter mode.
If the audit it reporting a netprobe event, this would suggest that you have either created the custom application incorrectly (wrong ports), haven't assigned the application in question to the rule, or the client service is actually using different ports to the ones you think it should be using.
All, Thanks for the suggestions, have tried all
here is what I am seeing
Dest Geo US (correct)
Dest Port 8080 (correct)
Dstip (Correct Destination IP)
Event TCP netprobe
Interface 1-1 (Internal interface)
Reason Received a TCP connection attempt destined for a service that the current policy does not support.
Source Port 60960
Source Zone internal (Correct)
Srcip (Correct source IP)
Syslog Warnings (4)
my application is set to TCP/UDP TCP port 8080
Setting the Application defense group on the Access control rule to Connection settings does not change anything
changing it to minimal proxy then causes it to become an attack,
I have no IPS on it, no Authenticator, no port redirects,
but still not letting it through properly
I know that the application is working somewhat as I have installed a second box which is now passing some information trough on that port but not all. (both using different versions of the same software one is the old server and one is the new server)
as the destination IPs for both of these IPs are the same and can be reached
Both are part of the same access control rule both internal IPs are both part of the same Source object group, and the destinations are all part of the same destination group.
For one IP it is like it is trying to filter stuff out of what goes out, if it does not understand it, and the second it does not like at all.