반응형

* 망 구성
10.100.30.101 -- VPN 1 -- ( Public ) -- VPN 2 (10.251.212.240) -- 10.90.65.182

10.100.30.101 -> 10.90.65.182로 pkt을 전송할 경우, 
VPN2 <-> 10.90.65.182 사이 망이 굉장히 복잡하여 10.100.30.101 - 10.90.65.182에 대한 라우팅을 설정할 수 없는 구간이다.

이에따라 아래와 같이 NAT를 설정했다.
NAT를 설정한 구간은, 10.100.30.101 --> 10.90.65.182 이며 'Use Outgoing Interface Address'를 설정했다.


* 설정방법
 . Policy & Objects > IPv4 Policy > 구간선택


* packet 확인
아래와 같이 10.100.30.101 -> 10.90.65.182 pkt이 인입될 경우
10.100.30.101은 10.251.212.240으로 Translation 되어 통신이 완료된다. 


FortiVPN # dia sniffer packet any 'host 10.90.65.182' 4
interfaces=[any]
filters=[host 10.90.65.182]
1.026395 iTest_server in 10.100.30.101.36277 -> 10.90.65.182.21: syn 2654734121 
1.026511 port4 out 10.251.212.240.36277 -> 10.90.65.182.21: syn 2654734121  
4.032451 iTest_server in 10.100.30.101.36277 -> 10.90.65.182.21: syn 2654734121 
4.032509 port4 out 10.251.212.240.36277 -> 10.90.65.182.21: syn 2654734121 
4.989417 iTest_server in 10.100.30.101.40113 -> 10.90.65.182.21: syn 3357824665 
4.989526 port4 out 10.251.212.240.40113 -> 10.90.65.182.21: syn 3357824665 
7.990786 iTest_server in 10.100.30.101.40113 -> 10.90.65.182.21: syn 3357824665 
7.990834 port4 out 10.251.212.240.40113 -> 10.90.65.182.21: syn 3357824665 

반응형
반응형

* VPN에서 Local Network로 Ping 되더라도, VPN Interface - Local Network간 대역이 다를 경우
Local Network에 대한 Routing을 추가해놓아야 한다.
왜?  VPN - Local Network간에는 대역이 동일 or 라우팅 설정 등으로 ping이 이미 되는 상황일 수 있으나,
Site-to-Site는 Remote Network 대역을 Source IP로, 우리 Local Network 대역에 붙어야 하기 때문.
따라서, Local Network <-- VPN <-- Remote Network로 pkt이 올 경우
정확한 가이드를 위해 VPN에서도 Local Network에 대해 라우팅 추가를 미리 설정해준다.

  
* 문제 현상
VPN에 Local Network와 ping이 되지만, 대역이 다른 경우에,
그리고 라우팅이 설정 안 되어 있을 경우, 아래와 같이 수신된 packet을 out 시킬 수 없다.
FortiVPN# dia sniffer packet nay 'host 10.100.30.101' 4
intefaces=[any]
filters=[host 10.100.30.101]
1.140135 iTest_server in 10.100.30.101 -> 10.90.65.182: icmp: echo request
6.142442 iTest_server in 10.100.30.101 -> 10.90.65.182: icmp: echo request
11.134851 iTest_server in 10.100.30.101 -> 10.90.65.182: icmp: echo request
21.124414 iTest_server in 10.100.30.101 -> 10.90.65.182: icmp: echo request


* 보완
Local Network에 대한 Routing을 설정 후, 아래와 같이 packet은 정상 out된다.
FortiVPN # dia sniffer packet any 'host 10.100.30.101' 4
interfaces=[any]
filters=[host 10.100.30.101]
73.304160 iTest_server in 10.100.30.101 -> 10.90.65.182: icmp: echo request
73.305211 iTest_server out 10.90.65.182 -> 10.100.30.101: icmp: echo reply
74.309417 iTest_server in 10.100.30.101 -> 10.90.65.182: icmp: echo request
74.312548 iTest_server out 10.90.65.182 -> 10.100.30.101: icmp: echo reply
249.096258 iTest_server out 10.90.65.182 -> 10.100.30.101: icmp: echo reply
250.098714 iTest_server out 10.90.65.182 -> 10.100.30.101: icmp: echo reply
^C
6 packets received by filter
0 packets dropped by kernel

반응형
반응형

* 우분투 18.04 버전 기반(Ubuntu 18.04)

1. vpnclient 프로그램 설치
sudo apt install vpnc network-manager-vpnc-gnome



2. 설정
root@VL-harbor:~# cat  /etc/vpnc/default.conf
#IPSec gateway <gateway>
#IPSec ID <group-id>
#IPSec secret <group-psk>
#IKE Authmode hybrid
#Xauth username <username>
#Xauth password <password>
※ sudo vpnc /etc/vpnc/default.conf 혹은 sudo vpnc \default.conf 


3. VPN 연결
# sudo vpnc-connect (끊을때는 sudo vpnc-disconnect)
예시)
root@VL-harbor:~# cat /etc/vpnc/default.conf
IPSec gateway [VPN Public IP]
IPSec ID [VPNGroupID]
IPSec secret [VPNGroup-password]
#IKE Authmode hybrid  ---> 주석 처리해도 무방함
Xauth username [VPN Client ID]
Xauth password [VPN Client password]
root@VL-harbor:~#


4. VPN 연결 확인:  sudo vpnc-connect 이후  ip addr 에서 tun0 로 client IP 할당 된것 확인가능
root@VL-harbor:~# ip addr

  : tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1412 qdisc fq_codel state UNKNOWN group default qlen 500    link/none
    inet 172.20.38.153/32 scope global tun0  //# Assigned
       valid_lft forever preferred_lft forever
    inet6 fe80::59bf:bd0d:ee37:3533/64 scope link stable-privacy
       valid_lft forever preferred_lft forever

 * 혹은 아래처럼 default route가 tun0 로 잡힌것도 확인 가능함
:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 tun0  //# set
121.137.98.146  150.100.200.1   255.255.255.255 UGH   0      0        0 ens3
150.100.200.0   0.0.0.0         255.255.255.0   U     0      0        0 ens3
172.20.38.152   0.0.0.0         255.255.255.248 U     0      0        0 tun0


* VPN 서버에서 split vpn 설정해두었다면, 외부망 ping도 가능
:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=3.87 ms\


위는 CLI 로 하는 방법이며, 리눅스에 GUI 가 있다면 아래 링크를 통해 GUI base 로도 설정 가능함.
https://johnpili.com/how-to-connect-to-a-cisco-vpn-in-ubuntu-18-04-lts/


출처: 부서의 VPN 전문가 선배님

반응형
반응형

양단의 IPSec이 Phase-2까지 Completed 되었으나 실제 local IP간 icmp가 실패하는 문제가 발생하였다.

이유를 확인하기 위해 Cisco ASDM의 Monitoring에서 해당ip로 Logging을 잡아보면, 아래와 같은 NAT 이슈가 발생하고 있다.

현상

5 Apr 28 2020 11:04:18 305013 10.10.0.214 20.20.20.50

Asymmetric NAT rules matched for forward and reverse flows; Connection for icmp src outside:10.10.0.214 dst AWS:20.20.20.50 (type 8, code 0) denied due to NAT reverse path failure

설명 및 해결방법

10.10.0.214 -> 20.20.20.50 connection에 대해 잘못된 NAT rule이 적용되어(동일하게 사용하는 existing pool이 또 있다는 것임), NAT reverse path failure로 인해 connection이 deny 되고있었다.

이는 해당 VPN Group의 NAT Exempt 설정을 dst쪽 network로 설정해주면 된다.

설정

Configuration > Site-to-Site VPN > Connection Profiles > 해당 Connection profile name 클릭 > Basic > NAT exempt > Exempt ASA side host/network from address translation 에서 dst쪽 inteface 선택.

이후 해당 vpn profile은 NAT Exemption이 되므로 connection은 정상연결 완료된다.

* NAT Exempt: This allows you to exempt the local network addresses from network translation.

반응형
반응형

 

문제가 발생했을 때 분석을 위해 알아본 Cisco ASA VPN의 packet 캡처 방법.

ASDM의 Monitoring에서 실시간 logging을 제공하나, ACL/NAT단에서 걸릴 경우 아무런 패킷도 Trace 창에 보이지 않게되는데, 이럴 때 유용한 패킷 캡처 방법이다.

 

1. packet capture 방법(설명)

- 출처: Cisco사 CLI 설명서 1: Cisco ASA Series 일반 운영 CLI 구성 가이드, 9.10 : 1223 page ~ 1228 page

옵션 값이 매우 많아서 자료를 그대로 들고왔다.

 

 

 

이렇게 패킷캡처를 설정한 후에는 아래와 같이 패킷 캡처를 보는 명령어가 별도로 존재한다.

패킷 캡처 설정 후, 아래 명령어를 실행해야 실제 캡처되는 패킷을 확인할 수 있다.

 

 

2. 설정 및 실습 - CLI

그렇게 직접 실습해 본 packet capture.

현재 20.20.20.50 - 20.20.20.246은 NAT 설정 오류로 인해 20.20.20.246 -> 20.20.20.50으로 Ping을 실행할 경우 packet이 drop되는 상태이다. 그래서 20.20.20.50 -> 20.20.20.246 방향과 20.20.20.246 -> 20.20.20.50 패킷 캡처를 진행해보았다.

 

1) packet capture

ciscoasa# capture CAP_TEMP_AWS buffer 2048 interface AWS match icmp host 20.20.20.246 any
ciscoasa# capture LOG_DROP type asp-drop all match ip host 20.20.20.50 host 20.20.20.246
ciscoasa# capture LOG_DROP type asp-drop all match ip host 20.20.20.246 host 20.20.20.50

 

2) show capture

packet 캡처를 설정 후, show capture를 통해 패킷 캡처를 확인한다.

#show capture    // 전체 capture되고 있는 packet capture 확인

Result of the command: "show capture"
capture CAP_TEMP_AWS type raw-data buffer 2048 interface AWS [Capturing - 456 bytes] 
  match ip host 20.20.20.246 any 
  match ip host 20.20.20.248 any 
capture LOG_DROP type asp-drop all [Buffer Full - 524284 bytes] 
  match ip host 20.20.20.50 host 20.20.20.248 

 

2-1) 전체 packet capture 확인

#show capture // 전체 capture되고 있는 packet capture 확인 Result of the command: "show capture" capture

 

CAP_TEMP_AWS type raw-data buffer 2048 interface AWS [Capturing - 456 bytes] match ip host 20.20.20.246 any match ip host 20.20.20.248 any capture LOG_DROP type asp-drop all [Buffer Full - 524284 bytes] match ip host 20.20.20.50 host 20.20.20.248

 

2-2) 특정 packet capture 확인

Remove the captures when done.

ciscoasa# no capture CAP_TEMP_AWS
ciscoasa# no capture LOG_DROP


그리고 원인 파악을 위해 show nat로 NAT를 확인한다.

설정된 NAT에는 패킷이 걸렸으나, 다른 이슈로 인해 untranslate가 되었다.

현재 왜 untranslate가 되었는지 파악하는 중이다.

 

2-2. 설정 및 실습 - ASDM

패킷캡처는 ASDM에서도 아래 방법을 통해 진행할 수 있다.

1) Configuration > Firewall > NAT Rules > Packet Trace

 

 

 

Packet Trace를 클릭 후 interface와 packet Type을 설정 후 설정값들을 입력하면 애니메이션과 함께 어떤 부분에서 어떤 rule이 적용됐는지 + 버튼을 통해 확인할 수 있다.

 

어떤 단계들을 거쳐왔는지 + 버튼을 통해 확인해본다.

 

 

 

반응형
반응형

Access-List

목적

VPN에서 새로운 Interface를 설정할 때 ACL을 설정해서

각 Remote-access로 접속하는 vpn client들에게 routing table을 내려주기 위함.

 

개념

Standard ACL: 발신지의 IP Adress만으로 Access를 제한. 번호는 1-99사용

Extended ACL: 발신의 IP/Port, 수신의 IP/Port를 사용하여 Access를 제한. 번호는 100-199 사용

 (더 자세한 설명은 아래 출처 링크 참고)

 

명령어

access-list [ACL NAME] standard permit 21.21.21.0 255.255.255.0    // ipsec 통신할 내부대역 지정

group-policy [Interface] attributes   // 설정한 Interface에 ACL 적용

split-tunnel-policy tunnelspecified   // split-tunnel 활성화 (Internet Traffic은 ASA로 오지 않고 client에서 바로 인터넷 사용)

split-tunnel-network-list value [ACL Name]   // 해당 ACL Traffic만 ipsec 통신 사용

ASDM

* ACL

Firewall > Advanced > ACL Manager or Standard ACL

- Standard ACL: Standard ACL에서 확인

- Extended ACL: ACL Manager에서 확인

* Client 라우팅 / Split-tunneling 설정

Remote Access VPN > Network Access > Group Policy > Group Policy 선택 > Edit > Advanced > Split Tunneling > Policy & NetworkList 선택

 

* Policy:Tunnel Network List Below를 설정해야 해당 Network List만 IPSEC 통신을 함. (이외는 모두 외부 통신)

 - Network List엔 Standard ACL만 있음.

 

 

ACL 개념 및 추가 출처

There are two types of IPv4 ACLs:

  • Standard ACLs: These ACLs permit or deny packets based only on the source IPv4 address.
  • Extended ACLs: These ACLs permit or deny packets based on the source IPv4 address and destination IPv4 address, protocol type, source and destination TCP or UDP ports, and more.

For example, Example 4-3 shows how to create a standard ACL. In this example, ACL 10 permits hosts on the source network 192.168.10.0/24. Because of the implied “deny any” at the end, all traffic except for traffic coming from the 192.168.10.0/24 network is blocked with this ACL.

https://www.ciscopress.com/articles/article.asp?p=3089353&seqNum=7

반응형

+ Recent posts