Problem with custom services

[kalysta]

Fortigate 100D running v5.0,build0292 (GA Patch 9)

I have created two custom services TCP 9100 and UDP 47808. I created two different policies one policy using each of the custom services. The firewall is blocking both of the services. The only way I can get the traffic through is to change the policy to allow all services. I even tried all allow ALL_UDP but upd/47808 was still being blocked. Currently I do have AV and IPS security profiles assigned to the policies, but I did try disabling all security services and the traffic was still being blocked. I have several other policies that are using custom services. The firmware was upgraded prior to any policies or services being created on this firewall. In other words, a firmware upgrade has not been done between the creation of the policies using custom services that are working and the creation of the policies using custom service that are not working. Any help would be greatly appreciated.

Below is a copy of the policies that aren't working

edit 13 set srcintf "port1" set dstintf "SSN300" set srcaddr "10.18.21.55" "172.30.128.17" "172.30.120.17" set dstaddr "10.69.1.119" "10.69.1.120" set action accept set schedule "always" set service "UDP-47808" set logtraffic all set capture-packet enable set comments "LGH\'s Siemens server to CSC panels"

edit 14 set srcintf "Aesynt370" set dstintf "port1" set srcaddr "Aesynt_Devices" set dstaddr "10.69.0.19" set action accept set schedule "always" set service "TCP_9100" set utm-status enable set logtraffic all set comments "Aesynt devices to printer" set av-profile "default" set ips-sensor "protect_client" set profile-protocol-options "default"

[Dave_Hall]

Most of the time when setting up custom services is it's the target port that you are setting up -- the source port should be left at 0-65535.

Also make sure you move these firewall policies above any general firewall policy rules so they are executed; firewall policies are executed from top-to-bottom.

[kalysta]

Dave Hall wrote:

Most of the time when setting up custom services is it's the target port that you are setting up -- the source port should be left at 0-65535.

[attachImg]https://forum.fortinet.com/download.axd?file=0;119911&where=message&f=Custom-Service.gif[/attachImg]

Also make sure you move these firewall policies above any general firewall policy rules so they are executed; firewall policies are executed from top-to-bottom.

I did configure the destination port as 9100 and 47808 and the source ports are configured as 0-65535. The other policies are not conflicting. I confirmed this by moving the new policies to the top of the list (the two policies I'm having problems with are on different firewall interfaces)

[rwpatterson]

I would next try to monitor the policy when you change it to 'all' to see if any other services are required in addition to the one you specified. Something else may be required that's not documented. It's happened before. (ask me how I know...)

[ede_pfau]

HP printing is (at least in one place, here: http://www.speedguide.net/port.php?port=9100) reported to use port 9100 TCP and UDP. Try the policy with the custom service extended by 9100/udp.

Be sure that the (test) traffic hits the intended policy. You can peek into the data stream in the CLI (console window) with

diag deb ena

diag sniffer packet <portname> 'port 9100' 4 0 a. If the reason for blocking is not obvious please post the diag output here.

[kalysta]

ede_pfau wrote:

HP printing is (at least in one place, here: http://www.speedguide.net/port.php?port=9100) reported to use port 9100 TCP and UDP. Try the policy with the custom service extended by 9100/udp.

Be sure that the (test) traffic hits the intended policy. You can peek into the data stream in the CLI (console window) with

diag deb ena

diag sniffer packet <portname> 'port 9100' 4 0 a. If the reason for blocking is not obvious please post the diag output here.

I added 9100/udp.I noticed in the logs viewed form the GUI when I allow all ports the log shows the firewall allowed the traffic with Policy ID 14 (which is correct), but if I change the policy to use SNMP, TCP/UDP 9100 it denies the traffic and references Policy ID 0 Below are the results of diag and screen shot of the log.

2877.264883 Aesynt370 -- 10.69.1.74.55560 -> 10.69.0.19.9100: syn 2258148774 

2880.266262 Aesynt370 -- 10.69.1.74.55560 -> 10.69.0.19.9100: syn 2258148774 

2886.268582 Aesynt370 -- 10.69.1.74.55560 -> 10.69.0.19.9100: syn 2258148774 

2903.260723 Aesynt370 -- 10.69.1.74.55566 -> 10.69.0.19.9100: syn 1633740168 

2906.261716 Aesynt370 -- 10.69.1.74.55566 -> 10.69.0.19.9100: syn 1633740168 

2912.263047 Aesynt370 -- 10.69.1.74.55566 -> 10.69.0.19.9100: syn 1633740168 

2929.265156 Aesynt370 -- 10.69.1.74.55571 -> 10.69.0.19.9100: syn 3922942513 

2932.261121 Aesynt370 -- 10.69.1.74.55571 -> 10.69.0.19.9100: syn 3922942513 

2938.266460 Aesynt370 -- 10.69.1.74.55571 -> 10.69.0.19.9100: syn 3922942513 

2960.269988 Aesynt370 -- 10.69.1.74.55576 -> 10.69.0.19.9100: syn 3384196890 

2963.272789 Aesynt370 -- 10.69.1.74.55576 -> 10.69.0.19.9100: syn 3384196890 

2969.275128 Aesynt370 -- 10.69.1.74.55576 -> 10.69.0.19.9100: syn 3384196890 

[Dave_Hall]

kalysta wrote:

set srcaddr "10.18.21.55" "172.30.128.17" "172.30.120.17"

set dstaddr "10.69.1.119" "10.69.1.120"

[...]

set dstaddr "10.69.0.19"

I'm not a big fan of address object labels using IP addresses - could/can lead to problems further down the road -- can you confirm these address labels are type subnet?

Policy #13 doesn't show NAT enabled, so are the devices at "10.69.1.119" "10.69.1.120" going to allow those 3 IP addresses to connect to them?

Regarding policy#14, if the dest or target device "10.69.0.19" is a network printer, you will want to log into it and confirmed it is setup/configured to allow the "Aesynt_Devices" to "talk" to it -- if this is not possible you may want to enable NAT on that policy as a possible work-around.

Regarding whether policies are working or not, if you do not want to get into the whole debug/sniffer stuff, you can always enable the count column on the policy screen.

[kalysta]

Dave Hall wrote:

kalysta wrote:

set srcaddr "10.18.21.55" "172.30.128.17" "172.30.120.17"

set dstaddr "10.69.1.119" "10.69.1.120"

[...]

set dstaddr "10.69.0.19"

I'm not a big fan of address object labels using IP addresses - could/can lead to problems further down the road -- can you confirm these address labels are type subnet?

Policy #13 doesn't show NAT enabled, so are the devices at "10.69.1.119" "10.69.1.120" going to allow those 3 IP addresses to connect to them?

Regarding policy#14, if the dest or target device "10.69.0.19" is a network printer, you will want to log into it and confirmed it is setup/configured to allow the "Aesynt_Devices" to "talk" to it -- if this is not possible you may want to enable NAT on that policy as a possible work-around.

Regarding whether policies are working or not, if you do not want to get into the whole debug/sniffer stuff, you can always enable the count column on the policy screen.

[attachImg]https://forum.fortinet.com/download.axd?file=0;119956&where=message&f=column count.gif[/attachImg]

I have confirmed the address objects are type subnet. I have attached a pic of one of the address objects

Policy #13 10.69.119 and 10.69.1.120 are already allowing the 3 IP address to communicate via telnet and ping. I also see communication on 47808/udp when configure the policy to allow all services so I don't think it has anything to do with the devices.

Policy #14 I have confirmed the printer is configured correctly and everything works fine when I configure the policy to allow all services.

I enabled the count column when I first created the rules. The count is going up but that is because each policy is allowing other services through. However, I will create a separate rule for the services I am having problems with. 

Below is the output of diag sniffer packet Aesynt370 'port 9100' and I attached a screenshot from the GUI log

2877.264883 Aesynt370 -- 10.69.1.74.55560 -> 10.69.0.19.9100: syn 2258148774

2880.266262 Aesynt370 -- 10.69.1.74.55560 -> 10.69.0.19.9100: syn 2258148774

2886.268582 Aesynt370 -- 10.69.1.74.55560 -> 10.69.0.19.9100: syn 2258148774

2903.260723 Aesynt370 -- 10.69.1.74.55566 -> 10.69.0.19.9100: syn 1633740168

2906.261716 Aesynt370 -- 10.69.1.74.55566 -> 10.69.0.19.9100: syn 1633740168

2912.263047 Aesynt370 -- 10.69.1.74.55566 -> 10.69.0.19.9100: syn 1633740168

2929.265156 Aesynt370 -- 10.69.1.74.55571 -> 10.69.0.19.9100: syn 3922942513

2932.261121 Aesynt370 -- 10.69.1.74.55571 -> 10.69.0.19.9100: syn 3922942513

2938.266460 Aesynt370 -- 10.69.1.74.55571 -> 10.69.0.19.9100: syn 3922942513

2960.269988 Aesynt370 -- 10.69.1.74.55576 -> 10.69.0.19.9100: syn 3384196890

2963.272789 Aesynt370 -- 10.69.1.74.55576 -> 10.69.0.19.9100: syn 3384196890

2969.275128 Aesynt370 -- 10.69.1.74.55576 -> 10.69.0.19.9100: syn 3384196890

[kalysta]

The policy using TCP 9100 is only using that port. It's simply windows printing. The policy using UDP 47808 is also using telnet and ICMP. Telnet and ICMP are passing through just fine. The log clearly shows it's blocking only TCP 9100 and UDP 47808. When I changed the policy to allow ALL UDP ports the firewall still blocked UDP 47808

[ashukla_FTNT]

To find out why firewall is dropping it, run the flow level debug:

diag debug enable diag debug flow filter dport 9100 diag debug flow show console enable diag debug flow trace start 200

start the traffic and after capturing the output disable the debug

diag debug disable

Post the output