> On 01/06/2018 04:07 PM, Colony.three via Shorewall-users wrote:
>
>>> -------- Original Message --------
>>> Subject: Re: [Shorewall-users] IPSec Tunneling
>>> Local Time: January 5, 2018 3:41 PM
>>> UTC Time: January 5, 2018 11:41 PM
>>> From: colony.th...@protonmail.ch
>>> To: Shorewall Users shorewall-users@lists.sourceforge.net
>>>
>>>> On 01/05/2018 03:02 PM, Colony.three via Shorewall-users wrote:
>>>>
>>>> On 01/05/2018 02:25 PM, Colony.three via Shorewall-users wrote:
>>>>
>>>> |I'm trying to change the listening port of Libreswan using
>>>> these DNAT entries in rules: DNAT net
>>>> local:192.168.1.16:500 udp - 5500 ð0 DNAT
>>>> net local:192.168.1.16 udp ipsec-nat-t -
>>>> ð0 ... but this results in the below DROPS. Rather than
>>>> forwarding the packets to that IP:port, it blocks them as
>>>> destined for the $FW. I don't understand why? IPSEC
>>>> connects fine when I don't try to change port 500. Also can I
>>>> combine these two DNAT lines? Or would that push everything
>>>> into 500? [53533.057543] Shorewall:net-fw:DROP:IN=eth0 OUT=
>>>> MAC=52:54:00:e6:0a:80:f6:b5:2f:a2:db:8e:08:00
>>>> SRC=172.58.46.201 DST=50.35.109.212 LEN=736 TOS=0x00
>>>> PREC=0x00 TTL=55 ID=11170 DF PROTO=UDP SPT=20563 DPT=65500
>>>> LEN=716 [53534.973338] Shorewall:net-fw:DROP:IN=eth0 OUT=
>>>> MAC=52:54:00:e6:0a:80:f6:b5:2f:a2:db:8e:08:00
>>>> SRC=172.58.46.201 DST=50.35.109.212 LEN=736 TOS=0x00
>>>> PREC=0x00 TTL=55 ID=11171 DF PROTO=UDP SPT=20563 DPT=65500
>>>> LEN=716 [53537.760649] Shorewall:net-fw:DROP:IN=eth0 OUT=
>>>> MAC=52:54:00:e6:0a:80:f6:b5:2f:a2:db:8e:08:00
>>>> SRC=172.58.46.201 DST=50.35.109.212 LEN=736 TOS=0x00
>>>> PREC=0x00 TTL=55 ID=11172 DF PROTO=UDP SPT=20563 DPT=65500
>>>> LEN=716 [53541.706546] Shorewall:net-fw:DROP:IN=eth0 OUT=
>>>> MAC=52:54:00:e6:0a:80:f6:b5:2f:a2:db:8e:08:00
>>>> SRC=172.58.46.201 DST=50.35.109.212 LEN=736 TOS=0x00
>>>> PREC=0x00 TTL=55 ID=11173 DF PROTO=UDP SPT=20563 DPT=65500
>>>> LEN=716 Install the conntrack utility and run 'conntrack
>>>> -F' and try again. -Tom |
>>>>
>>>> Thanks, but same DROPs. conntrack -F seemed to just hang, but when I
>>>> added the tables 'conntrack' and 'expect', it flushed immediately.
>>>> [56184.041321] Shorewall:net-fw:DROP:IN=eth0 OUT=
>>>> MAC=52:54:00:e6:0a:80:f6:b5:2f:a2:db:8e:08:00 SRC=172.58.46.201
>>>> DST=50.35.109.212 LEN=736 TOS=0x00 PREC=0x00 TTL=55 ID=11427 DF
>>>> PROTO=UDP SPT=3196 DPT=5500 LEN=716
>>>> [56185.906421] Shorewall:net-fw:DROP:IN=eth0 OUT=
>>>> MAC=52:54:00:e6:0a:80:f6:b5:2f:a2:db:8e:08:00 SRC=172.58.46.201
>>>> DST=50.35.109.212 LEN=736 TOS=0x00 PREC=0x00 TTL=55 ID=11428 DF
>>>> PROTO=UDP SPT=3196 DPT=5500 LEN=716
>>>> [56188.729401] Shorewall:net-fw:DROP:IN=eth0 OUT=
>>>> MAC=52:54:00:e6:0a:80:f6:b5:2f:a2:db:8e:08:00 SRC=172.58.46.201
>>>> DST=50.35.109.212 LEN=736 TOS=0x00 PREC=0x00 TTL=55 ID=11429 DF
>>>> PROTO=UDP SPT=3196 DPT=5500 LEN=716
>>>>
>>>>
>>>>
>>>> The DESTINATION port is 5500, not the SOURCE port. So your rules
>>>> need:
>>>>
>>>> DNAT net local:192.168.1.16:500 udp 5500 - ð0
>>>> DNAT net local:192.168.1.16 udp ipsec-nat-t - ð0
>>>>
>>>> -Tom
>>>
>>> Ah, so true. Now no more firewall messages, neither at the router nor
>>> the gateway, but still no connect with the changed port, but connect
>>> with 500. Nothing in /var/log/messages, and the only indication is in
>>> /var/log/secure . (below)
>>> I don't hope for help from you with Libreswan -- you've been more than
>>> generous with the (undeserving) Strongswan. But if you see what might
>>> be wrong, input is appreciated.
>>> /var/log/secure
>>> Jan 5 15:28:41 zeta pluto[54167]: packet from 172.58.46.194:42614:
>>> length of ISAKMP Message is smaller than minimum
>>> Jan 5 15:28:41 zeta pluto[54167]: packet from 172.58.46.194:42614:
>>> Received packet with mangled IKE header - dropped
>>> Jan 5 15:28:43 zeta pluto[54167]: packet from 172.58.46.194:42614:
>>> length of ISAKMP Message is smaller than minimum
>>> Jan 5 15:28:43 zeta pluto[54167]: packet from 172.58.46.194:42614:
>>> Received packet with mangled IKE header - dropped
>>> Jan 5 15:28:46 zeta pluto[54167]: packet from 172.58.46.194:42614:
>>> length of ISAKMP Message is smaller than minimum
>>> Jan 5 15:28:46 zeta pluto[54167]: packet from 172.58.46.194:42614:
>>> Received packet with mangled IKE header - dropped
>>> Jan 5 15:28:50 zeta pluto[54167]: packet from 172.58.46.194:42614:
>>> length of ISAKMP Message is smaller than minimum
>>> Jan 5 15:28:50 zeta pluto[54167]: packet from 172.58.46.194:42614:
>>> Received packet with mangled IKE header - dropped
>>> Jan 5 15:28:55 zeta pluto[54167]: packet from 172.58.46.194:42614:
>>> length of ISAKMP Message is smaller than minimum
>>> Jan 5 15:28:55 zeta pluto[54167]: packet from 172.58.46.194:42614:
>>> Received packet with mangled IKE header - dropped
>>> Jan 5 15:31:54 zeta pluto[54167]: packet from 172.58.43.178:19924:
>>> length of ISAKMP Message is smaller than minimum
>>> Jan 5 15:31:54 zeta pluto[54167]: packet from 172.58.43.178:19924:
>>> Received packet with mangled IKE header - dropped
>>> Jan 5 15:31:55 zeta pluto[54167]: packet from 172.58.43.178:19924:
>>> length of ISAKMP Message is smaller than minimum
>>> Jan 5 15:31:55 zeta pluto[54167]: packet from 172.58.43.178:19924:
>>> Received packet with mangled IKE header - dropped
>>> Jan 5 15:31:58 zeta pluto[54167]: packet from 172.58.43.178:19924:
>>> length of ISAKMP Message is smaller than minimum
>>> Jan 5 15:31:58 zeta pluto[54167]: packet from 172.58.43.178:19924:
>>> Received packet with mangled IKE header - dropped
>>> Jan 5 15:32:02 zeta pluto[54167]: packet from 172.58.43.178:19924:
>>> length of ISAKMP Message is smaller than minimum
>>> Jan 5 15:32:02 zeta pluto[54167]: packet from 172.58.43.178:19924:
>>> Received packet with mangled IKE header - dropped
>>> Jan 5 15:32:08 zeta pluto[54167]: packet from 172.58.43.178:19924:
>>> length of ISAKMP Message is smaller than minimum
>>> Jan 5 15:32:08 zeta pluto[54167]: packet from 172.58.43.178:19924:
>>> Received packet with mangled IKE header - dropped
>>> I have no idea what 172.58.43.178 is... certainly not my phone's Ip.
>>> Must be some kind of TMobile interlocutor.
>>
>> On the router I'm seeing the IPSec packets coming in -- or what appear
>> to be, as they're on the port I've substituted:
>>
>> tcpdump 'udp port 5500 and (((ip[2:2] - ((ip[0]&0xf)<<2)) -
>>
>> ((udp[12]&0xf0)>>2)) != 0)'
>> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
>> listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
>> 15:53:15.393979 IP 172.58.43.174.qdb2service >
>> draco.darkmatter.org.5500: UDP, length 708
>> 15:53:17.299826 IP 172.58.43.174.qdb2service >
>> draco.darkmatter.org.5500: UDP, length 708
>> 15:53:20.099326 IP 172.58.43.174.qdb2service >
>> draco.darkmatter.org.5500: UDP, length 708
>> 15:53:24.051977 IP 172.58.43.174.qdb2service >
>> draco.darkmatter.org.5500: UDP, length 708
>> 15:53:29.637394 IP 172.58.43.174.qdb2service >
>> draco.darkmatter.org.5500: UDP, length 708
>> ^C
>> 5 packets captured
>> 5 packets received by filter
>> 0 packets dropped by kernel
>> Then on the IPSec gateway I seem to also be seeing those packets:
>>
>> tcpdump 'udp port 500 and (((ip[2:2] - ((ip[0]&0xf)<<2)) -
>>
>> ((udp[12]&0xf0)>>2)) != 0)'
>> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
>> listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
>> 15:58:13.722242 IP 172.58.43.174.41546 > zeta.darkmtter.org.isakmp: isakmp:
>> 15:58:15.627860 IP 172.58.43.174.41546 > zeta.darkmtter.org.isakmp: isakmp:
>> 15:58:18.429562 IP 172.58.43.174.41546 > zeta.darkmtter.org.isakmp: isakmp:
>> 15:58:22.346575 IP 172.58.43.174.41546 > zeta.darkmtter.org.isakmp: isakmp:
>> 15:58:27.960118 IP 172.58.43.174.41546 > zeta.darkmtter.org.isakmp: isakmp:
>> ^C
>> 5 packets captured
>> 5 packets received by filter
>> 0 packets dropped by kernel
>> But Libreswan never sees them -- there is no recognition of any packets
>> in /var/log/messages. And in /var/log/secure:
>> Jan 6 15:59:50 zeta pluto[1991]: packet from 172.58.43.174:32544:
>> Received packet with mangled IKE header - dropped
>> Jan 6 15:59:52 zeta pluto[1991]: packet from 172.58.43.174:32544:
>> length of ISAKMP Message is smaller than minimum
>> Jan 6 15:59:52 zeta pluto[1991]: packet from 172.58.43.174:32544:
>> Received packet with mangled IKE header - dropped
>> Jan 6 15:59:55 zeta pluto[1991]: packet from 172.58.43.174:32544:
>> length of ISAKMP Message is smaller than minimum
>> Jan 6 15:59:55 zeta pluto[1991]: packet from 172.58.43.174:32544:
>> Received packet with mangled IKE header - dropped
>> Jan 6 15:59:59 zeta pluto[1991]: packet from 172.58.43.174:32544:
>> length of ISAKMP Message is smaller than minimum
>> Jan 6 15:59:59 zeta pluto[1991]: packet from 172.58.43.174:32544:
>> Received packet with mangled IKE header - dropped
>> Jan 6 16:00:04 zeta pluto[1991]: packet from 172.58.43.174:32544:
>> length of ISAKMP Message is smaller than minimum
>> Jan 6 16:00:04 zeta pluto[1991]: packet from 172.58.43.174:32544:
>> Received packet with mangled IKE header - dropped
>> Jan 6 16:00:06 zeta pluto[1991]: packet from 172.58.43.174:32544:
>> length of ISAKMP Message is smaller than minimum
>> Jan 6 16:00:06 zeta pluto[1991]: packet from 172.58.43.174:32544:
>> Received packet with mangled IKE header - dropped
>> So the UDP packets are getting torn up in the process of converting from
>> port 5500 to 500. This is the DNAT I'm using in rules:
>> DNAT net local:192.168.111.16:500 udp 5500 - ð0
>> DNAT net local:192.168.111.16 udp ipsec-nat-t -
>> ð0
>> It works fine and I connect with no trouble when I don't try to change
>> the port. But when I try to change the port it will not connect.
>
> Then don't change the port.
>
> -Tom
So I told the doctor, "Doc, when I move my arm this way, it hurts." The doc
says, "well then don't move your arm this way."
You're better than that Tom, although you may not admit it. Maybe you're angry
with me for my frustration over Strongswan, but that is not relevant anymore.
This no longer has anything to do with Strongswan.
There are a hundred million bots trying everything on common ports, with known
vulns as well as zero-days. They can not try every port so 99% of them
concentrate on the low-hanging fruit. I am in enterprise infosec, and security
is layering.
It would be best if I could change this port, and there is some reason that my
packets are getting torn up. Maybe you don't have the answer but maybe someone
will recognize the merit of this effort and will pitch in. This is the only
place to ask about the mechanics of Shorewall after all.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
