New Member

Solved

Problem with custom services

Forum|Forum|11 years ago
February 5, 2015
8 replies
30515 views

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"

Best answer by ashukla_FTNT

If you check the custom service from CLI do you see :0 after portrnage

config firewall service custom edit "TCP_9100" set tcp-portrange 9100:0

If you see portrange 9100:0 it is a problem.

Either from cli just set tcp-portrange 9100

Of in Webui in source port start make it blank insted or 0.

Dave_Hall

New Member

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.

Custom-Service.gif

kalystaAuthor

New Member

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

New Member

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

SuperUser

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.

kalystaAuthor

New Member

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

log.JPG

Dave_Hall

New Member

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.

column count.gif

kalystaAuthor

New Member

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

log.JPG

kalystaAuthor

New Member

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

Staff

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

kalystaAuthor

New Member

ashukla wrote:
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

Below is the output. I don't know why its referencing Policy 0. The policy is also below. It's a different number than my previous ports because I separated out tcp/udp/9100

edit 18 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" "UDP-9100" "SNMP" 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" next

Output of debug:

id=13 trace_id=1 msg="vd-root received a packet(proto=6, 10.69.1.74:56278->10.69.0.19:9100) from Aesynt370. flag , seq 2906141963, ack 0, win 8192" id=13 trace_id=1 msg="allocate a new session-01467199" id=13 trace_id=1 msg="find a route: flags=00000000 gw-10.69.1.33 via port1" id=13 trace_id=1 msg="use addr/intf hash, len=4" id=13 trace_id=1 msg="Denied by forward policy check (policy 0)" id=13 trace_id=2 msg="vd-root received a packet(proto=6, 10.69.1.74:56278->10.69.0.19:9100) from Aesynt370. flag , seq 2906141963, ack 0, win 8192" id=13 trace_id=2 msg="allocate a new session-014671a7" id=13 trace_id=2 msg="find a route: flags=00000000 gw-10.69.1.33 via port1" id=13 trace_id=2 msg="use addr/intf hash, len=4" id=13 trace_id=2 msg="Denied by forward policy check (policy 0)" id=13 trace_id=3 msg="vd-root received a packet(proto=6, 10.69.1.74:56278->10.69.0.19:9100) from Aesynt370. flag , seq 2906141963, ack 0, win 8192" id=13 trace_id=3 msg="allocate a new session-014671be" id=13 trace_id=3 msg="find a route: flags=00000000 gw-10.69.1.33 via port1" id=13 trace_id=3 msg="use addr/intf hash, len=4" id=13 trace_id=3 msg="Denied by forward policy check (policy 0)" id=13 trace_id=4 msg="vd-root received a packet(proto=6, 10.69.1.74:56283->10.69.0.19:9100) from Aesynt370. flag , seq 3562697345, ack 0, win 8192" id=13 trace_id=4 msg="allocate a new session-014671ef" id=13 trace_id=4 msg="find a route: flags=00000000 gw-10.69.1.33 via port1" id=13 trace_id=4 msg="use addr/intf hash, len=4" id=13 trace_id=4 msg="Denied by forward policy check (policy 0)" id=13 trace_id=5 msg="vd-root received a packet(proto=6, 10.69.1.74:56283->10.69.0.19:9100) from Aesynt370. flag , seq 3562697345, ack 0, win 8192" id=13 trace_id=5 msg="allocate a new session-014671f7" id=13 trace_id=5 msg="find a route: flags=00000000 gw-10.69.1.33 via port1" id=13 trace_id=5 msg="use addr/intf hash, len=4" id=13 trace_id=5 msg="Denied by forward policy check (policy 0)" id=13 trace_id=6 msg="vd-root received a packet(proto=6, 10.69.1.74:56283->10.69.0.19:9100) from Aesynt370. flag , seq 3562697345, ack 0, win 8192" id=13 trace_id=6 msg="allocate a new session-0146723b" id=13 trace_id=6 msg="find a route: flags=00000000 gw-10.69.1.33 via port1" id=13 trace_id=6 msg="use addr/intf hash, len=4" id=13 trace_id=6 msg="Denied by forward policy check (policy 0)" id=13 trace_id=7 msg="vd-root received a packet(proto=6, 10.69.1.74:56288->10.69.0.19:9100) from Aesynt370. flag , seq 2330396767, ack 0, win 8192" id=13 trace_id=7 msg="allocate a new session-01467265" id=13 trace_id=7 msg="find a route: flags=00000000 gw-10.69.1.33 via port1" id=13 trace_id=7 msg="use addr/intf hash, len=4" id=13 trace_id=7 msg="Denied by forward policy check (policy 0)" id=13 trace_id=8 msg="vd-root received a packet(proto=6, 10.69.1.74:56288->10.69.0.19:9100) from Aesynt370. flag , seq 2330396767, ack 0, win 8192" id=13 trace_id=8 msg="allocate a new session-0146726a" id=13 trace_id=8 msg="find a route: flags=00000000 gw-10.69.1.33 via port1" id=13 trace_id=8 msg="use addr/intf hash, len=4" id=13 trace_id=8 msg="Denied by forward policy check (policy 0)" id=13 trace_id=9 msg="vd-root received a packet(proto=6, 10.69.1.74:56288->10.69.0.19:9100) from Aesynt370. flag , seq 2330396767, ack 0, win 8192" id=13 trace_id=9 msg="allocate a new session-0146727c" id=13 trace_id=9 msg="find a route: flags=00000000 gw-10.69.1.33 via port1" id=13 trace_id=9 msg="use addr/intf hash, len=4" id=13 trace_id=9 msg="Denied by forward policy check (policy 0)" id=13 trace_id=10 msg="vd-root received a packet(proto=6, 10.69.1.74:56294->10.69.0.19:9100) from Aesynt370. flag , seq 3413926227, ack 0, win 8192" id=13 trace_id=10 msg="allocate a new session-014672da" id=13 trace_id=10 msg="find a route: flags=00000000 gw-10.69.1.33 via port1" id=13 trace_id=10 msg="use addr/intf hash, len=4" id=13 trace_id=10 msg="Denied by forward policy check (policy 0)" id=13 trace_id=11 msg="vd-root received a packet(proto=6, 10.69.1.74:56294->10.69.0.19:9100) from Aesynt370. flag , seq 3413926227, ack 0, win 8192" id=13 trace_id=11 msg="allocate a new session-014672e0" id=13 trace_id=11 msg="find a route: flags=00000000 gw-10.69.1.33 via port1" id=13 trace_id=11 msg="use addr/intf hash, len=4" id=13 trace_id=11 msg="Denied by forward policy check (policy 0)" id=13 trace_id=12 msg="vd-root received a packet(proto=6, 10.69.1.74:56294->10.69.0.19:9100) from Aesynt370. flag , seq 3413926227, ack 0, win 8192" id=13 trace_id=12 msg="allocate a new session-014672f2" id=13 trace_id=12 msg="find a route: flags=00000000 gw-10.69.1.33 via port1" id=13 trace_id=12 msg="use addr/intf hash, len=4" id=13 trace_id=12 msg="Denied by forward policy check (policy 0)" id=13 trace_id=13 msg="vd-root received a packet(proto=6, 10.69.1.74:56300->10.69.0.19:9100) from Aesynt370. flag , seq 1097075618, ack 0, win 8192" id=13 trace_id=13 msg="allocate a new session-01467330" id=13 trace_id=13 msg="find a route: flags=00000000 gw-10.69.1.33 via port1" id=13 trace_id=13 msg="use addr/intf hash, len=4" id=13 trace_id=13 msg="Denied by forward policy check (policy 0)" id=13 trace_id=14 msg="vd-root received a packet(proto=6, 10.69.1.74:56300->10.69.0.19:9100) from Aesynt370. flag , seq 1097075618, ack 0, win 8192" id=13 trace_id=14 msg="allocate a new session-01467339" id=13 trace_id=14 msg="find a route: flags=00000000 gw-10.69.1.33 via port1" id=13 trace_id=14 msg="use addr/intf hash, len=4" id=13 trace_id=14 msg="Denied by forward policy check (policy 0)"

ashukla_FTNTAnswer

Staff

If you check the custom service from CLI do you see :0 after portrnage

config firewall service custom edit "TCP_9100" set tcp-portrange 9100:0

If you see portrange 9100:0 it is a problem.

Either from cli just set tcp-portrange 9100

Of in Webui in source port start make it blank insted or 0.

rwpatterson

New Member

ashukla wrote:
If you check the custom service from CLI do you see :0 after portrnage

config firewall service custom edit "TCP_9100" set tcp-portrange 9100:0
If you see portrange 9100:0 it is a problem.
Either from cli just set tcp-portrange 9100
Of in Webui in source port start make it blank insted or 0.

Is this correct?

ashukla_FTNT

Staff

rwpatterson wrote:
ashukla wrote:
If you check the custom service from CLI do you see :0 after portrnage

config firewall service custom edit "TCP_9100" set tcp-portrange 9100:0
If you see portrange 9100:0 it is a problem.
Either from cli just set tcp-portrange 9100
Of in Webui in source port start make it blank insted or 0.

Is this correct?

Yes it is right. If source port start range is left to 0 it will show up as 9100:0 which causes the problem. It should be 1.

In future releases we will not see the option for source port at all as are hardly anyone restricting the source port.