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

Digi TransPort WR (Series)
,
1

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

2

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

3

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.

4

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

5

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

6

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

7

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

8

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

9

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

10

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

11

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

12

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

13

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

14

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

15

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

16

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

17

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

18

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.

19

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

20

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