IPSec VPN에서 패킷 사이즈가 크면 통신이 잘 안 되는 이슈가 있어 연구하다가 이 글을 씀.
파란색은 클라우드, 노란색은 On-prem
노란색 VPN은 포티게이트 장비이다.
포티게이트 장비에서 대충 아래와 같이 때려 박았다.
Fortigate
config firewall policy
edit <policy id>
set tcp-mss sender 1350
set tcp-mss receiver 1350
config system interface
edit <Phase 1 name>
set mtu-override enable
set mtu 1400
일단 TCP 테스트는 할 수 없는 상황이라 보류하고....
일단 여러 가지 테스트 중에 클라우드 서버의 MTU를 바꿔보기로 했다.
그리고 포티게이트에서 diagnose vpn tunnel list name <phase 1 name> 명령어로 MTU를 확인해보니 1422다.
이상해서 열심히 뒤져보니 fnsysctl ifconfig <phase 1 name> 명령어로 확인해보니 1400이다.
왜?????
구성도를 다시 확인해보자.
이 상황에서 클라우드에서 On-Prem으로 ping 테스트를 하였다.
케이스 1. ping 10.10.10.11 -c 1 -w 1 -s 1400
14:02:23.342392 78:9a:bc:12:34:56 > 12:34:56:78:9a:bc, ethertype IPv4 (0x0800), length 1410: 192.168.1.4 > 10.10.10.11: ICMP echo request, id 116, seq 1, length 1376
14:02:23.342401 78:9a:bc:12:34:56 > 12:34:56:78:9a:bc, ethertype IPv4 (0x0800), length 66: 192.168.1.4 > 10.10.10.11: ip-proto-1
1428 사이즈의 패킷이 발생
출발지에서 Fragmentation 발생
응답을 못 받음
케이스 2. ping 10.10.10.11 -c 1 -w 1 -s 1372
14:02:43.649217 78:9a:bc:12:34:56 > 12:34:56:78:9a:bc, ethertype IPv4 (0x0800), length 1414: 192.168.1.4 > 10.10.10.11: ICMP echo request, id 117, seq 1, length 1380
14:02:43.656462 12:34:56:78:9a:bc > 78:9a:bc:12:34:56, ethertype IPv4 (0x0800), length 1414: 10.10.10.11 > 192.168.1.4: ICMP echo reply, id 117, seq 1, length 1380
1400 사이즈의 패킷이 발생 1372 + 8(ICMP) + 20(IP)
정상
케이스 3. ping 10.10.10.11 -c 1 -w 1 -s 1373
14:02:57.769475 78:9a:bc:12:34:56 > 12:34:56:78:9a:bc, ethertype IPv4 (0x0800), length 1410: 192.168.1.4 > 10.10.10.11: ICMP echo request, id 118, seq 1, length 1376
14:02:57.769483 78:9a:bc:12:34:56 > 12:34:56:78:9a:bc, ethertype IPv4 (0x0800), length 39: 192.168.1.4 > 10.10.10.11: ip-proto-1
14:02:57.778047 12:34:56:78:9a:bc > 78:9a:bc:12:34:56, ethertype IPv4 (0x0800), length 1415: 10.10.10.11 > 192.168.1.4: ICMP echo reply, id 118, seq 1, length 1381
1401 사이즈의 패킷이 발생
해당 목적지로의 MTU가 1400이기에 출발지에서 Fragmentation 발생
응답은 1개로 옴 (목적지에서 Fragmentation 하지 않음)
케이스 4. ping 10.10.10.11 -c 1 -w 1 -s 1394
14:03:34.347857 78:9a:bc:12:34:56 > 12:34:56:78:9a:bc, ethertype IPv4 (0x0800), length 1410: 192.168.1.4 > 10.10.10.11: ICMP echo request, id 119, seq 1, length 1376
14:03:34.347868 78:9a:bc:12:34:56 > 12:34:56:78:9a:bc, ethertype IPv4 (0x0800), length 60: 192.168.1.4 > 10.10.10.11: ip-proto-1
14:03:34.357053 12:34:56:78:9a:bc > 78:9a:bc:12:34:56, ethertype IPv4 (0x0800), length 1436: 10.10.10.11 > 192.168.1.4: ICMP echo reply, id 119, seq 1, length 1402
1422 사이즈의 패킷이 발생
해당 목적지로의 MTU가 1400이기에 출발지에서 Fragmentation 발생
응답은 1개로 옴 (목적지에서 Fragmentation 하지 않음)
케이스 5. ping 10.10.10.11 -c 1 -w 1 -s 1395
14:04:11.175944 78:9a:bc:12:34:56 > 12:34:56:78:9a:bc, ethertype IPv4 (0x0800), length 1410: 192.168.1.4 > 10.10.10.11: ICMP echo request, id 120, seq 1, length 1376
14:04:11.175956 78:9a:bc:12:34:56 > 12:34:56:78:9a:bc, ethertype IPv4 (0x0800), length 61: 192.168.1.4 > 10.10.10.11: ip-proto-1
1423 사이즈의 패킷이 발생
해당 목적지로의 MTU가 1400이기에 출발지에서 Fragmentation 발생
응답을 못 받음
응답을 왜 못 받았을까?
응답 못 받은 사유를 추적해보면
① 출발지 단말에서 echo request 패킷 2개로 Fragmentation 하여 보냄
② 목적지 단말에서 echo request 패킷 2개를 받고 조합함
③ 목적지 단말에서 echo reply 패킷을 Fragmentation하지 않고 보냄
④ 목적지 VPN에서 Encapsulation 하여 보냈는데 ESP가 1514 bytes를 초과하게 되어 Fragmentation 발생함
=> 이게 영향을 준 것으로 보임
Fragmentation 패킷은 On-Prem 방화벽과 인터넷 라우터 모두 통과했음
증거 있냐고?
아 있지. 패킷~
빨간색을 보면 ESP 패킷이 분할되어 클라우드 VPN으로 전송되었다.
그럼 해결해야지
2000 바이트씩 핑 쳐도 분할해서 나가게끔 만들어 줘야지
상황을 보아하니 Encapsulation 다음에 Fragmentation 들어가는 게 문제다.
Fragmentation 하고 Encapsulation 하면 문제없지 않을까? 하여 찾아보니 있다.
Fortigate
config vpn ipsec phase1-interface
edit <name>
set ip-fragmentation pre-encapsulation
Technical Tip: Fragment IP packets before IPsec en... - Fortinet Community
케이스 5 다시 해보자. ping 10.10.10.11 -c 1 -w 1 -s 1395
16:27:03.221761 78:9a:bc:12:34:56 > 12:34:56:78:9a:bc, ethertype IPv4 (0x0800), length 1410: 192.168.1.4 > 10.10.10.11: ICMP echo request, id 134, seq 1, length 1376
16:27:03.221767 78:9a:bc:12:34:56 > 12:34:56:78:9a:bc, ethertype IPv4 (0x0800), length 61: 192.168.1.4 > 10.10.10.11: ip-proto-1
16:27:03.230329 12:34:56:78:9a:bc > 78:9a:bc:12:34:56, ethertype IPv4 (0x0800), length 1410: 10.10.10.11 > 192.168.1.4: ICMP echo reply, id 134, seq 1, length 1376
16:27:03.230329 12:34:56:78:9a:bc > 78:9a:bc:12:34:56, ethertype IPv4 (0x0800), length 61: 10.10.10.11 > 192.168.1.4: ip-proto-1
그러고 나니 1395 이상도 귀신같이 된다.
아까는 On-Prem VPN에서 ESP가 1514 바이트를 초과하면서 Fragmentation이 되었는데
이번에는 Fragmentation 먼저 된 거 같고 각 Fragmentation 된 패킷들이 Encapsulation 되어서 클라우드 VPN으로 전송되었다.
① 출발지 단말에서 echo request 패킷 2개로 Fragmentation 하여 보냄
② 목적지 단말에서 echo request 패킷 2개를 받고 조합함
③ 목적지 단말에서 echo reply 패킷을 Fragmentation하지 않고 보냄
④ 목적지 VPN에서 echo reply 패킷을 Fragmentation 후 Encapsulation 하여 전송
⑤ 출발지 단말에서 Fragmentation 된 echo reply 패킷 2개를 모두 받고 재조합함
그리고 좀 뒤져보니 post-encapsulation에서 속도 저하 이슈가 있다는 문서가 있던데..
이 경우는 저하가 아니라 그냥 안 되는 거었다.
지금 클라우드 통신 속도 저하 이슈 케이스가 있는데 연관이 있을지도 모르니 이번 테스트 결과를 토대로 여러 가지 해볼게 생긴 것 같다.
Note:
You really want to avoid fragmentation after encapsulation when you do hardware encryption with IPv4sec. Hardware encryption can give you throughput of about 50 Mbs which depends on the hardware, but if the IPv4sec packet is fragmented you loose 50 to 90 percent of the throughput. This loss is because the fragmented IPv4sec packets are process-switched for reassembly and then handed to the Hardware encryption engine for decryption. This loss of throughput can bring hardware encryption throughput down to the performance level of software encryption (2-10 Mbs).
Resolve IPv4 Fragmentation, MTU, MSS, and PMTUD Issues with GRE and IPsec - Cisco
'Network TroubleShooting' 카테고리의 다른 글
| 클라우드 서비스가 안 돼요-VPN 편 (3/?) (0) | 2022.04.28 |
|---|---|
| 내가 패킷을 까는 이유 (0) | 2022.04.27 |
| 인트로 (0) | 2022.01.03 |
댓글