ICMP UDP port 500 unreachable when I have daemon binded on that port

D

double

Hello everyone.
Short version:

FreeBSD 12.0
IPSec via StrongSwan.

tcpdump:
Code: 
IP 1.1.1.1.61160 > 2.2.2.2.500: isakmp: phase 1 I ident
IP 2.2.2.2 > 1.1.1.1: ICMP 2.2.2.2 udp port 500 unreachable, length 444

sockstat:
Code: 
root     charon     1367  13 udp4   *:500                 *:*
root     charon     1367  14 udp4   *:4500                *:*

pfctl -s rules -P
Code: 
pass in quick on tun0 inet proto udp from any to 2.2.2.2 port = 500 keep state

Why my FreeBSD sends ICMP about UDP port 500 unreachable when I have daemon binded to that port?

Details:

After I've changed ISP, L2TP connection don't work anymore.
New ISP delivers internet via PPPoE, old one had straight connection.
All I did to FreBSD and services configurations is just changed staic IP from old to new and changed name of interface in PF config file.
And I swear to god, it worked first day, I have log : )
After that I wrote script that checks internet availability and runs services after PPP establishes connection and reboot, I guess after that IPSec stopped working.
I have no idea why it happens. IPSec don't work now even if all services is stopped and that script suspended too.
SSHD via TCP and OpenVPN via UDP work fine when I run them.
 
This is what I have:
Code: 
pass in quick on $ext_if proto esp from $home to ($ext_if)
pass in quick on $ext_if proto ah from $home to ($ext_if)
pass in quick on $ext_if proto ipencap from $home to ($ext_if)
pass in quick on $ext_if proto udp from $home port = 500 to ($ext_if) port = 500
$home is the IP address of my home connection. I have an IPSec tunnel from my home network to my VPS. Outgoing traffic isn't filtered (I probably should but never got around to it).

double said:
Why my FreeBSD sends ICMP about UDP port 500 unreachable when I have daemon binded to that port?
Click to expand...
Why are you returning ICMP UDP port unreachable at all? Even if the daemon wasn't listening you should not respond, packet should get dropped. Returning a RST on a TCP connection is fine, ICMP responses should be avoided at all costs (only a few ICMP responses are 'ok', ICMP echo reply for example; UDP port unreachable isn't).
 
This is what I have:
Click to expand...
1.1.1.1 in my example is static IP too, so I desperatly added to pf.conf something like
Code: 
pass quick 1.1.1.1
If my understanding is right it should eleminate all possible blocks from connections between 1.1.1.1 to 2.2.2.2

Why are you returning ICMP UDP port unreachable at all?
Click to expand...
My bad.

1. But I'd like to know who generate that ICMP packet is that system driver or may be badly configured IPSec daemon?
2. If somehow IPSec daemon runs before tun0 created is that possible that sockstat displays *:500 but in reality daemon not binded to tun0 500 UDP port. Is there any way do check it?

PS: I've turned off autorun of strongswan and run it manually, but it doesnt help. When I stop strongswan, charon disapears from sockstat.
 
double said:
If somehow IPSec daemon runs before tun0 created is that possible that sockstat displays *:500 but in reality daemon not binded to tun0 500 UDP port. Is there any way do check it?
Click to expand...
IKE doesn't run inside the tunnel, it runs outside of it.
 
SirDice said:
IKE doesn't run inside the tunnel, it runs outside of it.
Click to expand...
My new ISP(on the VPN server side) deliver internet connecion over PPPoE and I'm pretty sure that I was able establish L2TP/IPSec(IKEv1) connection through PPPoE.
It seems to me that some how StrongSwan's daemon charon don't listen UPD 500 port, but sockstat show opposite, and I'd like to find out what is going on and why.
 
double said:
My new ISP(on the VPN server side) deliver internet connecion over PPPoE and I'm pretty sure that I was able establish L2TP/IPSec(IKEv1) connection through PPPoE.
Click to expand...
Two different things here. When I spoke of the 'tunnel' I meant the IPSec tunnel, not the PPPoE connection.

But yes, it's possible IKE may come up before your PPPoE connection is set up. In which case IKE might not be bound to your external address. Restart IKE when the PPPoE connection is up, does it connect then?
 
SirDice said:
Restart IKE when the PPPoE connection is up
Click to expand...
Unfortunatly I've tried it. Not working.
I've tried to fully simulate state bofore. Turned off script, turned off services and all start manually including PPP client, but no success. I even thinked taht ISP is corrupting packets, but ICMP helped with that, seems like my router rejects packets on 500 UDP port.
My current connection looks like:
(VPN Router[2.2.2.2])<--PPPoE-->(ISP[2.2.2.1])-----(Internet)-----([1.1.1.1]L2TP/IPSec client)

Is that possible to check to what interfaces exacly bind IPSec daemon and who generate ICMP packet?
 
Run tcpdump(1) on the host, capturing UDP 500 and ICMP. Then make the connection. See what actually happens. You might not receive anything, in which case the traffic gets blocked somewhere upstream.
 
SirDice said:
Run tcpdump(1) on the host, capturing UDP 500 and ICMP.
Click to expand...

At my very first message I wrote result of tcpdump. UDP packet recieved, ICMP packet sended. When I've seen result or tcpdump, I've checked sockstats if any one listening 500 UDP and then I wonder why is socket binded but OS still replies with ICMP unreachable.

Or may be I didn't understand your idea.
 
Thank you all for replies. I found my mistake. Problem was in NAT rule. Shame.
We had bigger subnet of static IP adresses and one LAN located NAS device with VPN software on board and it had dedicated WAN static IP address. I did some experiments and left one NAT rule for IPSec/OpenVPN ports. And now we have only one static WAN IP address, PF redirected incoming packets to that NAS and it rejected with ICMP.
 
You must log in or register to reply here.
Back
Top