Home/Support/Support Forum/Ca I have a specific FW script for use on a specific interface?
Welcome to Digi Forum, where you can ask questions and receive answers from other members of the community.

Ca I have a specific FW script for use on a specific interface?

0 votes
Hello:

We have a WR44 connected via GRE tunnels inside IPSec tunnels over GPRS via ppp1.
We have the FW enabled currently on ppp1 as follows:

#Allow outbound FTP traffic
pass out break end proto ftp from any to any port=ftpcnt flags S!A inspect-state
#Allow any other outbound traffic and the replies back in
pass out break end inspect-state
#Allow incoming IPSEC
pass break end proto 50
pass in break end proto udp from any to any port=ike
pass in break end proto udp from any to any port=4500
#Allow any traffic within an IPSEC tunnel in both directions
pass break end oneroute any
#Allow incoming SSH and SFTP
pass in break end proto tcp from any to any port=22222 flags S!A inspect-state
#Allow incoming HTTPS
pass in break end proto tcp from any to any port=443 flags S!A inspect-state
#Block and log everything else including incoming telnet, http and FTP
block log break end

This is working fine.

Our problem is, the instrumentation we have at the site sends a real-time stream over the link from source TCP port 5018 and this is the traffic we are interested in. The system also stores its data locally and at the top of the hour, the central server will check if any data is missing, if it is it will passively ftp it up from the instrument. The problem is this ftp session swamps the BW of the link causing the real-time data to get delayed during the ftp.

What we want to do is prioritize the source TCP port 5018 traffic over the ftp data.

This source data enters interface eth0 and leaves interface ppp1.

The FW rule to mark the data should be something like this:
dscp 46 in on eth0 proto tcp from any to any port=5018

Can someone confirm that?

Now, my thinking is that I should mark this packet as it comes INTO the router on eth0, is that correct?
Question: If I enable the fw on eth0 all FW rules will be in effect on eth0, right? I don't want to block anything on eth0 from coming into the router but there is only a single fw.txt file in the router which means whichever interface I enable this on, all the rules will apply, right? Which means I lock myself out of my http interface on eth0 if I enable the fw on eth0....so how do I do this?

Then, I enable QoS on interface ppp1, is that correct?

In short, I need a clarification on whether I need to enable the FW on eth0, on ppp1 or on both. If I do it on both, how do I do so that I don't block myself our of the web interface on eth0?

Sorry for the dump questions.

Cheers,
john
asked May 3, 2018 in Digi TransPort Cellular by jserink Community Contributor (74 points)

Please log in or register to answer this question.

6 Answers

0 votes
OK the first part of the question you can add a rule to be intrested on the traffic on eth 0

pass break end on eth 0

this is a catch all rule for the eth 0 interface to allow all traffic

then you would create a rule for the traffic you claim its source address is on port 5018 so the rule would be

you would have the port on the first any as this is source

dscp 46 in on eth0 proto tcp from any port=5018 to any

i take it you have read

http://ftp1.digi.com/support/documentation/QN_015_Quality%20of%20Service%20(QoS)%20on%20a%20TransPort%20router.pdf

as the data is from eth -> wan you are mainly intrested on fixing bandwidth on the uplink and as such you need to make sure the bandwidth out off WAN is priority for your steam and not FTP

so the next thing is to set qos up on the PPP interface and estimate the bandwidth you think you are going to get on the UP channel.

your not realy intrested in qos inbound witch is harder as the packets will have hit the interface and is already consuming bandwidth until TCP backs off

regards

James
answered May 3, 2018 by James.Wilson Veteran of the Digi Community (1,227 points)
0 votes
Hi James:

Ok, great. So, just to review:
I add these rules to the FW script:
pass break end on eth 0
dscp 46 in on eth0 proto tcp from any port=5018 to any

Ans this won't affect what the FW is doing on ppp1, right?

Now, the PPP1 BW estimation is a bit tricky as I have 16 sites in various areas, about half on 3G, some on Edge, some on GPRS class 12 so I don't really know what my max BW. In this type of case, how would you recommend I set the BW?

Cheers,
john

PS. Yes I read QN15 but that note:
1. It assumed a knowledge of the uplink BW,
2. The source was a specific IP,
3. the FW was operating on only in the incoming interface.

All of those are different in my application.
answered May 3, 2018 by jserink Community Contributor (74 points)
you also have to include the

pass end break on eth 0

after your rule this should allow all traffic in and out of eth 0

if you do not you will lock yourself out again
0 votes
Hi James:

So I add this to the fw.txt:

dscp 46 in on eth0 proto tcp from any port=5018 to any
pass break end on eth 0


Should I add that at the top of the fw script or the bottom?

After that, i just adjust the QoS on ppp1, correct?


Cheers,
john
answered May 3, 2018 by jserink Community Contributor (74 points)
the firewall rules are read top down so you need your rules at the top

then yes enable qos on ppp 1 and set the bandwidth
0 votes
Hi Everyone:

I tried to enter these rules into my test router and got this:
1 pass in break end proto icmp icmp-type echo
2 dscp 46 in on eth0 proto tcp from any port=5018 to any
# Error(line 2): Interface Expected
0 3 #Allow outbound FTP traffic

Here is my current fw.txt.
This is applied to ppp1.
pass in break end proto icmp icmp-type echo
#Allow outbound FTP traffic
pass out break end proto ftp from any to any port=ftpcnt flags S!A inspect-state
#Allow any other outbound traffic and the replies back in
pass out break end inspect-state
#Allow incoming IPSEC
pass break end proto 50
pass in break end proto udp from any to any port=ike
pass in break end proto udp from any to any port=4500
#Allow any traffic within an IPSEC tunnel in both directions
pass break end oneroute any
#Allow incoming SSH and SFTP
pass in break end proto tcp from any to any port=22222 flags S!A inspect-state
#Allow incoming HTTPS
pass in break end proto tcp from any to any port=443 flags S!A inspect-state
#Block and log everything else including incoming telnet, http and FTP
block log break end

So the FW editor throws that error when I try and add the line.

What am i doing wrong?

Cheers,
john
answered May 11, 2018 by jserink Community Contributor (74 points)
Hi

in this case the interface should have a space

"Eth 0" not eth0

this then should work

sorry my bad

dscp 46 in on eth 0 proto tcp from any port=5018 to any
pass break end on eth 0

regards

James
0 votes
Hi James:

Got that and got it in the FW script.
Now, before I do anything else, how can I check its working?

What I have done is this:
netsh interface portproxy add v4tov4 listenport=5018 listenaddress=192.168.173.10 connectport=7 connectaddress=192.168.173.10

What this does is take any TCP connection request for 192.168.173.10:5018 and internally send it to tcp port 7, the echo service, and then send it back out TCP 5018.
Here is netstat when I am connected using telnet 192.168.173.10 5018:
C:\>netstat -a -p tcp -n | find "5018"
TCP 192.168.173.10:5018 0.0.0.0:0 LISTENING
TCP 192.168.173.10:5018 192.168.111.199:40964 ESTABLISHED

You can see the socket is connected to 192.168.173.10:5018....but the Configuration - Security > Firewall shows no hits on rule 2:
dscp 46 in on eth 0 proto tcp from any port=5018 to any

There is also nothing here:
Management - Network Status > Firewall

How can I check if the fw tagging is working?


Second question:
I did some testing using hping like this:
hping -p 5018 -c 20 -s 6000 -d 2000 -S 192.168.173.10

But the results were nonsense and it occurred to me that hping doesn't actually establish the tcp connection, it just send sync packets so the FW in the digi might not be tagging them. As such, it would mean I can't use hping for testing.

Cheers,
john
answered May 14, 2018 by jserink Community Contributor (74 points)
Is the 5018 the source or destination port you are trying to prioritise.

as at the start you state source.

you would need to enable the analyser trace on the inbound port and see if it is modife as shown in the quick note

regards

James
Hi James:
Ok, I've setup the analyzer, here are my rules:
Layer 2 ticked,
layer 3 ticked,
Ethernet Interfaces, ETH0 ticked,
IP Sources, ETH0 ticked,
IP packet filters:
TCP/UDP Ports: ~5018
IP Addresses: ~192.168.173.10.....(my test machine with a TCP echo running on 5018),
Save that to power up settings.

I think Run this from a machine on the other side of the IPSec tunnels over GPRS so that the packets are coming in over IPSec, routed out to the test machine at 192.168.173.10 where they bounce off (echo off) 192.168.173.10:5018 and come back into the WR44 on Eth0.
I use this to generate my packets:
hping -p 5018 -c 5 -s 6000 -d 2000 -S 192.168.173.10

And here is one of the responses (they're all the same):
-----   15-5-2018  08:12:57.170   ------
   45 00 00 2C 58 10 40 00 80 06 04 99 C0 A8 AD 0A     E..,X.@.........
   C0 A8 6F C7 13 9A 17 70 89 0E 81 6D 4B 70 D3 A2     ..o....p...mKp..
   60 12 20 00 85 5A 00 00 02 04 05 B4 00 00           `. ..Z........
   
   IP (In) From REM TO LOC       IFACE: ETH 0
   45             IP Ver:        4
                  Hdr Len:       20
   00             TOS:           Routine
                  Delay:         Normal
                  Throughput:    Normal
                  Reliability:   Normal
   00 2C          Length:        44
   58 10          ID:            22544
   40 00          Frag Offset:   0
                  Congestion:    Normal
                                 Don't Fragment
                                 Last Fragment
   80             TTL:           128
   06             Proto:         TCP
   04 99          Checksum:      1177
   C0 A8 AD 0A    Src IP:        192.168.173.10
   C0 A8 6F C7    Dst IP:        192.168.111.199
   TCP:
   13 9A          SRC Port:      ??? (5018)
   17 70          DST Port:      ??? (6000)
   89 0E 81 6D    SEQ Number:    2299429229
   4B 70 D3 A2    ACK Number:    1265685410
   60 12          Flags
                  Data Offset    24
                                 SYN
                                 ACK
   20 00          Window:        8192
   85 5A          Checksum:      34138
   00 00          URG Ptr:       0
   02             TCP_OPT:       MSS (1460)
   ----------

As you can see, the TOS field says routine, Delay says normal, Throughput says normal, Reliability is normal.

Here is my FW script:
pass in break end proto icmp icmp-type echo
dscp 46 in on eth 0 proto tcp from any port=5018 to any
pass break end on eth 0
#Allow outbound FTP traffic
pass out break end proto ftp from any to any port=ftpcnt flags S!A inspect-state
#Allow any other outbound traffic and the replies back in
pass out break end inspect-state
#Allow incoming IPSEC
pass break end proto 50
pass in break end proto udp from any to any port=ike
pass in break end proto udp from any to any port=4500
#Allow any traffic within an IPSEC tunnel in both directions
pass break end oneroute any
#Allow incoming SSH and SFTP
pass in break end proto tcp from any to any port=22222 flags S!A inspect-state
#Allow incoming HTTPS
pass in break end proto tcp from any to any port=443 flags S!A inspect-state
#Block and log everything else including incoming telnet, http and FTP
block log break end

I have the "Enable FW" ticked on ppp1 only. If I tick it on eth 0 then I lose connection to the router and I have to come back in on the GRE tunnel address.

QoS is enabled on ppp1, link speed set to 2000.
Queue profiles are:
0   1800    2000   50  25  50  10  1
4   1000    2000   50  25  50  10  1

It appears I'm doing something wrong, its probably something dumb but hey, its me.

Cheers,
john
I repeated this test but instead of using hping I used telnet 192.168.173.10 5018 as I wanted to see if things behaving any differently if the TCP session was established rather than just sync packets.

The results were the same.

Cheers,
john
hi you are intrested in the packets coming in over the ethernet port and as such you have to have the firewall on ETH 0

the firewall rules should allow access to the ethernet port when you enable the firewall you would have to re-enable web access to the device.

you might need to add INSPECT-STATE to the end of rule 3

regards

James
Hi James:

I need the FW on both PPP1, which is Internet facing, and on Eth0 to mark the packets I need for QoS.

Does the WR44 support that?

So do I have to tick the FW box on the Eth0 interface settings?

Cheers,
john
the WR44 should support that what you have to be carefull with the firewalls to still allow access to the router.

how are you connecting to it?

when you enable firewall on an interface it can break connections on that interface as there are no records in the firewall table for previous communications.

hope that helps
Hi James:

For management I'm connecting via the GRE interface. I can still ping 192.168.173.10 which is the host connected to eth0.
line 3 I should change to this:
pass break end on eth 0 INSPECT-STATE

Every second packet TO 5018 is getting marked critical but none of the packets from 5018 are market critical. Do we have rule 3 setup properly?

Cheers,
john
When I send 5 hping TCP packets through, the FW counter shows but the analyzer trace shows the packets marked in the wrong direction.

I did an FTP transfer with hpings going through and the QoS did not manage the traffic as it should have, the hpings were heavily delayed so I think something is still amiss with the packet marking.

Cheers,
john
I bet the packets coming in from the gre are not tagged  are you tagging the packets coming from the remote site.

you are not going to get the packets coming into the router from GRE as you have already going through the router and as they exit eth 0 they are going from smaller channel to larger cellular -> eth.
Here are some examples from the analyzer:
This one is correct:
IP (Final) From LOC TO REM    IFACE: ETH 0
45             IP Ver:        4
               Hdr Len:       20
00             TOS:           Routine
               Delay:         Normal
               Throughput:    Normal
               Reliability:   Normal
05 C4          Length:        1476
00 1B          ID:            27
20 00          Frag Offset:   0
               Congestion:    Normal
                              May Fragment
                              More fragments
3D             TTL:           61
06             Proto:         TCP
B9 F6          Checksum:      47606
C0 A8 6F C7    Src IP:        192.168.111.199
C0 A8 AD 0A    Dst IP:        192.168.173.10
TCP:
17 70          SRC Port:      ??? (6000)
13 9A          DST Port:      ??? (5018)
2F 4E 20 82    SEQ Number:    793649282
50 E9 85 B0    ACK Number:    1357481392
50 02          Flags
               Data Offset    20
                              SYN
02 00          Window:        512
9D 62          Checksum:      40290
00 00          URG Ptr:       0

This one appears to be wrong:
IP (In) From REM TO LOC       IFACE: ETH 0
   45             IP Ver:        4
                  Hdr Len:       20
   00             TOS:           Routine
                  Delay:         Normal
                  Throughput:    Normal
                  Reliability:   Normal
   00 2C          Length:        44
   28 82          ID:            10370
   40 00          Frag Offset:   0
                  Congestion:    Normal
                                 Don't Fragment
                                 Last Fragment
   80             TTL:           128
   06             Proto:         TCP
   34 27          Checksum:      13351
   C0 A8 AD 0A    Src IP:        192.168.173.10
   C0 A8 6F C7    Dst IP:        192.168.111.199
   TCP:
   13 9A          SRC Port:      ??? (5018)
   17 70          DST Port:      ??? (6000)
   73 4F A3 BF    SEQ Number:    1934599103
   2F 4E 20 83    ACK Number:    793649283
   60 12          Flags
                  Data Offset    24
                                 SYN
                                 ACK
   20 00          Window:        8192
   48 09          Checksum:      18441
   00 00          URG Ptr:       0
   02             TCP_OPT:       MSS (1460)

As you can see the protocol is TCP, the source IP is 192.168.173.10 and the source port is 5018 but TOS is normal.

This next one is wrong as well:
IP (Final) From LOC TO REM    IFACE: ETH 0
45             IP Ver:        4
               Hdr Len:       20
B8             TOS:           CRITIC/ECP
               Delay:         Low
               Throughput:    High
               Reliability:   Normal
00 28          Length:        40
08 B6          ID:            2230
40 00          Frag Offset:   0
               Congestion:    Normal
                              Don't Fragment
                              Last Fragment
3E             TTL:           62
06             Proto:         TCP
95 3F          Checksum:      38207
C0 A8 6F C7    Src IP:        192.168.111.199
C0 A8 AD 0A    Dst IP:        192.168.173.10
TCP:
17 70          SRC Port:      ??? (6000)
13 9A          DST Port:      ??? (5018)
2F 4E 20 83    SEQ Number:    793649283
00 00 00 00    ACK Number:    0
50 04          Flags
               Data Offset    20
                              RST
00 00          Window:        0
96 E2          Checksum:      38626
00 00          URG Ptr:       0

the source socket is 192.168.111.199:6000 and the destination socket is 192.168.173.10:5018 and yet its TOS has been marked critical.
This appears to be in the wrong direction, no?

Cheers,
john
Hi James:

Ok, just so we're on the same page, I've got a laptop with windows 10 on it and the fw off. i've installed simple TCP services which has the echo service on port 7. I've put this cool little proxy in:
netsh interface portproxy add v4tov4 listenport=5018 listenaddress=192.168.173.10 connectport=7 connectaddress=192.168.173.10

which re-routes traffic from TCP 5018 to TCP 7 and back again to simulate my traffic originating from TCP 5018.

The Digi is connected to my lab via a Cisco 2811 using GRE over IPSec and my laptop is connected to the LAN with the Cisco.
I send hping traffic from my machine to the target laptop which is 192.168.173.10:5018 and I get the following responses:
jserinki7 /home/jserink/bin # hping -p 5018 -c 5 -s 6000 -d 2000 -S 192.168.173.10
HPING 192.168.173.10 (enp0s31f6 192.168.173.10): S set, 40 headers + 2000 data bytes
len=46 ip=192.168.173.10 ttl=126 DF id=10370 sport=5018 flags=SA seq=0 win=8192 rtt=51.8 ms
len=46 ip=192.168.173.10 ttl=126 DF id=10371 sport=5018 flags=SA seq=1 win=8192 rtt=40.6 ms
len=46 ip=192.168.173.10 ttl=126 DF id=10372 sport=5018 flags=SA seq=2 win=8192 rtt=37.5 ms
len=46 ip=192.168.173.10 ttl=126 DF id=10373 sport=5018 flags=SA seq=3 win=8192 rtt=34.3 ms
len=46 ip=192.168.173.10 ttl=126 DF id=10374 sport=5018 flags=SA seq=4 win=8192 rtt=86.1 ms

--- 192.168.173.10 hping statistic ---
5 packets tramitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 34.3/50.0/86.1 ms

So, those packets went from my laptop (linux) to the Cisco, into the GRE tunntels inside the IPSec tunnel over the GPRS into the Digi, out of the IPSec out of the GRE to the Ethernet to the target 192.168.173.10. Then the traffic is echoed back.

Now, the way I understand it, the traffic originating from 192.168.173.10:5018 should get marked with dscp 49....but the analyzer tracer shows that is not happening. The traffic going OUT of the Ethernet port  to 192.168.173.10:5018 is getting marked. I have QoS enabled on ppp1 which means there is not QoS happening at all because the packets in the wrong direction are getting marked.

This actually makes sense as when I do and ftp from the target which doing hping everything gets delayed whereas if the QoS was working it would not, so I think the analyzer is telling the truth.

Thoughts?

Here are my FW rules (note I have added the source IP address just to make sure):
pass in break end proto icmp icmp-type echo
dscp 46 in on eth 0 proto tcp from 192.168.173.10  port=5018 to any
pass break end on eth 0
#Allow outbound FTP traffic
pass out break end proto ftp from any to any port=ftpcnt flags S!A inspect-state
#Allow any other outbound traffic and the replies back in
pass out break end inspect-state
#Allow incoming IPSEC
pass break end proto 50
pass in break end proto udp from any to any port=ike
pass in break end proto udp from any to any port=4500
#Allow any traffic within an IPSEC tunnel in both directions
pass break end oneroute any
#Allow incoming SSH and SFTP
pass in break end proto tcp from any to any port=22222 flags S!A inspect-state
#Allow incoming HTTPS
pass in break end proto tcp from any to any port=443 flags S!A inspect-state
#Block and log everything else including incoming telnet, http and FTP
block log break end

Thoughts?

John
so the problem is if you followed the QOS quick note

the packet coming into eth 0 is showing the state coming in to the router at this point the firewall rule would modify the packet and you would need to trace further down the route so in the QN it is doing the trace at the PPP interface and shows the packet leaving with priority.

In your case the packets are pushed into GRE and then IPSEC as they enter these the TOS of the GRE is modified and also the IPSEC so if you trace the PPP for the ESP (proto 50) you should see some with priority TOS and some with out

are you marking the packets on the cisco coming in ?
Hi James:

Ok, i think i see where you're going here. So, if i am tracing packets on Eth 0 i won't see any modifications done to those packets by the firewall becasue those modificatons haven't happened yet. If i want to see the modified TOS fields, i need to look at the outgoing interface of ppp1. Do i follow you correctly?

I am doing no traffic management on the cisco, everything is default.

cheers,
john
Hi John that is correct and as you are leaving the wan interface as GRE in IPSec you should see the TOS of the IPSec as being modified.

the reasson you could see some packets out off eth being tagged is because they are a part of a stream and the firewall could have tagged them coming back in your example it was a reset om the stream

regards

James
Hi James:

Ok, this is excellent, making progress.
I changed my trace to capture packets at the ppp1 end and sent through 5 hping packets bouncing off TCP 5018 and indeed, the modified DCSP packets were there as expected so excellent.

Ech hping 2000 byte packet shows up as 6 ppp1 packets, all marked as CRITIC/ECP. It sjust hard as hell to find them in all the crud that is going over the link.
The first packet is always a GRE packet from 2.2.2.8 to 1.1.1.1 (1.1.1.1 is my GRE and IPSec loopback address in the Cisco). The second, third, forth and fifth packets are always ESP packets from the GPRS outside interface IP to my Cisco's public IP. The sixth and last packet is again GRE from 2.2.2.8 to 1.1.1.1. This sequence repeated for each hping message I send.
Ok, that all works as it should, the FW is marking the correct traffic DONE.

Now my problem is the QoS, no matter what settings I use on PPP1, does not seem to be working.

I'm testing this by downloading, via ftp, a file on the test laptop behind the Digi while I do my hpings.  If the QoS is working, the ftp should slow down, as compared to when there is no QoS, and the RTTs for the Hping should not change since I'm fixing the 5018 traffic's BW. My problem is, I'm seeing ZERO change no matter what settings I put in for the Configuration - Network > QoS > Queue Profiles.

I've measured my thru-put on the link and found it to be close to 2.3Mbps.
So I set the Profile 0 min BW to 2000 and the max to 2300. Then I set the profile 4 min BW to 10 and the max to 10....and there is zero change. The FTP session swamps the link slowing down my 5018 packets.

I think I'm setting something incorrectly here.

Cheers,
john
Are you ftping the file from the laptop behind the digi or from somewhere on the internet?

if from the internet its not going to work as the ftp data would be already on the interface off PPP so you have already fludded the link.  only the control channel would be slowed down.

you would need qos in to the PPP and this would have to be done by the ISP / Internet

if its from the laptop then it should work as shown in the appl;ication note

regards

james

regards

James
Hi James:

sorry, i was not clear.
the ftp server is on the laptop behind the digi. This simulates exactly the instrumentation we have on site, a device with an ftp server and a real-time stream on 5018. I need to keep the latency on the 5018 stream down even during an ftp upload.

Problem is, its not working. The ftp upload speed is completely consistant regardless of the QoS values i select and the latency jump on the 5018 data goes from ~40ms to 400ms. I've done this before on Debian based routers and use the HTB qdisc and it works perfectly. This should accomplish the same thing, its just not working. The packets are marked correctly, its like the QoS is just not doing anything.

Scratching my head here.

cheers,
john
Hi try reducing the

Queue profiles are:
0   1800    2000   50  25  50  10  1
4   1000    2000   50  25  50  10  1

so q4 has a smaller max value 1000

this should just cam the q4

regards
ok, will try that in the morning.
any other suggestion in case that one doesn't work?

cheers,
john
ok, will try that in the morning.
any other suggestion in case that one doesn't work?

Might the router require a reboot before the settings take effect?

cheers,
john
0 votes
James!!!

The reboot fixed it.
It works like magic, lovely.

I guess when I change something on ppp1 I need to cycle the interface.

Cheers,
john
answered May 16, 2018 by jserink Community Contributor (74 points)
Hi John.

i never remember which options on PPP need to have the interface reloaded (ppp 1 deact_rq) to take effect.

clad you got it working

regards

James
...