From: Naveen BN <nav...@gl...> - 2009-12-17 10:28:33
|
Hi All, I require some guidance on achieving a challenging work.* *I need to added the public Ip address different from that of local ip address in the inner IP header before passing it to IPSec processing . I have a tunnel mode policy based on public ip address and corresponding sa. Later the outer Ip header added by ipsec layer need to contain local ip address. I tried doing the same by using a SNAT using the command iptables -t nat -A POSTROUTING -s 172.16.8.36 -d 172.16.8.38 -j SNAT --to 172.16.8.2 Ipsec policy and sa details add 172.16.8.2 172.16.8.38 esp 0x301 -m tunnel -E 3des-cbc 0xf6ddb555acfd9d77b03ea3843f2653255afe8eb5573965df -A hmac-md5 0x96358c90783bbfa3d7b196ceabe0536b; add 172.16.8.38 172.16.8.36 esp 0x301 -m tunnel -E 3des-cbc 0xf6ddb555acfd9d77b03ea3843f2653255afe8eb5573965df -A hmac-md5 0x96358c90783bbfa3d7b196ceabe0536b; spdadd 172.16.8.2 172.16.8.38 any -P out ipsec esp/tunnel/172.16.8.36-172.16.8.38/require; spdadd 172.16.8.38 172.16.8.2 any -P in ipsec esp/tunnel/172.16.8.38-172.16.8.36/require; * * /* Packet from UE in case of UDP encapsulated Tunnel Mode */ -------------------------------------------------------------- |OUTER.| ESP | Inner IP | | | ESP | ESP| |IP | Hdr | Header | TCP | Data | Trailer|Auth| -------------------------------------------------------------- The contents of the above shown Packet w.r.t IP headers are interpreted as below Outer IP adder SRC ? Private IP address of UE DEST ?X IP address Inner IP adder SRC ? Public IP address of UE DEST ? X IP address # ping 172.16.8.38 PING 172.16.8.38 (172.16.8.38) 56(84) bytes of data. ping: sendmsg: Operation not permitted ping: sendmsg: Operation not permitted ping: sendmsg: Operation not permitted But i was not successful in sending the first out going esp packet, is there a way to achieve the same. Thanks and Regards Naveen |
From: Timo T. <tim...@ik...> - 2009-12-17 14:33:27
|
Naveen BN wrote: > I require some guidance on achieving a challenging work.* *I need to > added the public Ip address different from that > of local ip address in the inner IP header before passing it to IPSec > processing . I have a tunnel mode policy based on > public ip address and corresponding sa. Later the outer Ip header added > by ipsec layer need to contain local ip address. > > I tried doing the same by using a SNAT using the command > iptables -t nat -A POSTROUTING -s 172.16.8.36 -d 172.16.8.38 -j SNAT > --to 172.16.8.2 That sounds just wrong. You should add both public IP's to your server. Bind the processes to the public IP they use, and use the other as gateway address for the IPsec SA. - Timo |
From: Naveen BN <nav...@gl...> - 2009-12-18 08:01:26
|
Dear Timo, This what is expected in a UE as per TS 33.203. This feature should be present in UE as UDP encapsulated Tunnel mode if UE detects it is behind NAT. This out going packet from UE should look like Packet from UE in case of UDP encapsulated Tunnel Mode */ -------------------------------------------------------------- |OUTER.| UDP | ESP | Inner IP | | | ESP | ESP| |IP | Hdr | Hdr | Header | TCP | Data | Trailer|Auth| -------------------------------------------------------------- The contents of the above shown Packet w.r.t IP headers are interpreted as below Outer IP adder SRC ? Private IP address of UE DEST ? PCSCF IP address Inner IP adder SRC ? Public IP address of UE DEST ? PCSCF IP address ** ** Regards Naveen Timo Teräs wrote: > Naveen BN wrote: >> I require some guidance on achieving a challenging work.* *I need to >> added the public Ip address different from that >> of local ip address in the inner IP header before passing it to IPSec >> processing . I have a tunnel mode policy based on >> public ip address and corresponding sa. Later the outer Ip header >> added by ipsec layer need to contain local ip address. >> >> I tried doing the same by using a SNAT using the command >> iptables -t nat -A POSTROUTING -s 172.16.8.36 -d 172.16.8.38 -j SNAT >> --to 172.16.8.2 > > That sounds just wrong. You should add both public IP's to your > server. Bind the processes to the public IP they use, and use > the other as gateway address for the IPsec SA. > > - Timo > |
From: Timo T. <tim...@ik...> - 2009-12-18 08:11:51
|
Hi, Naveen BN wrote: > This what is expected in a UE as per TS 33.203. This feature should be > present in UE as UDP encapsulated Tunnel mode > if UE detects it is behind NAT. > > This out going packet from UE should look like > Packet from UE in case of UDP encapsulated Tunnel Mode */ > -------------------------------------------------------------- > |OUTER.| UDP | ESP | Inner IP | | | ESP | ESP| > |IP | Hdr | Hdr | Header | TCP | Data | Trailer|Auth| > > -------------------------------------------------------------- > > The contents of the above shown Packet w.r.t IP headers are interpreted > as below > Outer IP adder > SRC ? Private IP address of UE > DEST ? PCSCF IP address > Inner IP adder > SRC ? Public IP address of UE > DEST ? PCSCF IP address ** > ** I'm not really sure what you are actually trying to achieve, and not too interested to read 100+ pages. However, if a) the idea is to tunnel public IP traffic over link with private IPs, my previous suggestion stands: add the public IP to some interface in the server, so the applications can use the public IP automatically. b) It's some "auto detect my public IP and use that inside the tunnel" type thingy. This would need support in the keying daemon so that the tunnel addresses are negotiated properly. However, I don't really like this since the public IP can change without notice by the NAT device: it could have public IP pool, several different connections with different IPs and your SA's would need to be renegotiated. - Timo |
From: Naveen BN <nav...@gl...> - 2009-12-18 08:44:53
|
Timo, Change of Public IP at NAT will be take care by sending Nat keep alive . Yes i need to tunnel Public IP of UE learned. But the problem i have is adding the public IP in to the inner IP and tunnel it with a private IP . Regards Naveen Timo Teräs wrote: > Hi, > > Naveen BN wrote: >> This what is expected in a UE as per TS 33.203. This feature should >> be present in UE as UDP encapsulated Tunnel mode >> if UE detects it is behind NAT. >> >> This out going packet from UE should look like >> Packet from UE in case of UDP encapsulated Tunnel Mode */ >> -------------------------------------------------------------- >> |OUTER.| UDP | ESP | Inner IP | | | ESP | ESP| >> |IP | Hdr | Hdr | Header | TCP | Data | Trailer|Auth| >> >> -------------------------------------------------------------- >> The contents of the above shown Packet w.r.t IP headers are >> interpreted as below >> Outer IP adder >> SRC ? Private IP address of UE >> DEST ? PCSCF IP address >> Inner IP adder >> SRC ? Public IP address of UE >> DEST ? PCSCF IP address ** >> ** > > I'm not really sure what you are actually trying to achieve, and > not too interested to read 100+ pages. > > However, if > a) the idea is to tunnel public IP traffic over link with private IPs, > my previous suggestion stands: add the public IP to some interface > in the server, so the applications can use the public IP automatically. > > b) It's some "auto detect my public IP and use that inside the tunnel" > type thingy. This would need support in the keying daemon so that the > tunnel addresses are negotiated properly. However, I don't really like > this since the public IP can change without notice by the NAT device: > it could have public IP pool, several different connections with > different > IPs and your SA's would need to be renegotiated. > > - Timo > |
From: Timo T. <tim...@ik...> - 2009-12-18 09:04:47
|
Naveen BN wrote: > Change of Public IP at NAT will be take care by sending Nat keep > alive Yes, but only for the ISAKMP SA. IPsec SA is still usually done for the private IP in normal case. If public IP changes and the IPsec SA is for that public IP, you need to renegotiate the IPsec SA. > Yes i need to tunnel Public IP of UE learned. But the problem > i have is adding the public IP in to the inner IP and tunnel it with > a private IP . a) the IPsec SA needs to be negotiated with the public IP b) the application you run on the public IP needs to be aware that it's public IP has changed You really do need to add the public IP on your local server first or have the server application do some sort of binding to non-local IP-address which needs heavy support from kernel and is out of scope for this mailing list. - Timo |
From: Naveen BN <nav...@gl...> - 2009-12-18 09:23:14
|
Dear Timo, Your are right we need to renegotiate for change of public IP address. Can i bind the application with the public IP address learned or at which layer can i do this. Thanks and Regards Naveen Timo Teräs wrote: > Naveen BN wrote: >> Change of Public IP at NAT will be take care by sending Nat keep >> alive > > Yes, but only for the ISAKMP SA. IPsec SA is still usually done > for the private IP in normal case. > > If public IP changes and the IPsec SA is for that public IP, you > need to renegotiate the IPsec SA. > >> Yes i need to tunnel Public IP of UE learned. But the problem >> i have is adding the public IP in to the inner IP and tunnel it with >> a private IP . > > a) the IPsec SA needs to be negotiated with the public IP > b) the application you run on the public IP needs to be aware that > it's public IP has changed > > You really do need to add the public IP on your local server first > or have the server application do some sort of binding to non-local > IP-address which needs heavy support from kernel and is out of scope > for this mailing list. > > - Timo > |
From: Timo T. <tim...@ik...> - 2009-12-18 09:27:25
|
Naveen BN wrote: > Your are right we need to renegotiate for change of public IP address. > Can i bind the application with the public IP address learned or at > which layer can i do this. I think easiest is that you have dummy0 interface, and you assign the public IP to that interface. That way the application needs to just bind to a specific interface. There was recently added some non-local binding stuff to the linux kernel. But it's a separate API and needs explicit support from the application. In either case, what you need to do depends on the application and is out of scope for this mailing list. - Timo |
From: Naveen BN <nav...@gl...> - 2009-12-18 09:32:38
|
Dear Timo, Thank you for your solutions for adding public IP address. From where will the Ipsec layer read the ip address to add to outer IP header , as per my knowledge it should be from sa policy. Please correct me Regards Naveen Timo Teräs wrote: > Naveen BN wrote: >> Your are right we need to renegotiate for change of public IP address. >> Can i bind the application with the public IP address learned or at >> which layer can i do this. > > I think easiest is that you have dummy0 interface, and you assign the > public IP to that interface. That way the application needs to just > bind to a specific interface. > > There was recently added some non-local binding stuff to the linux > kernel. But it's a separate API and needs explicit support from the > application. > > In either case, what you need to do depends on the application and > is out of scope for this mailing list. > > - Timo > |
From: Timo T. <tim...@ik...> - 2009-12-18 09:39:26
|
Naveen BN wrote: > Thank you for your solutions for adding public IP address. > From where will the Ipsec layer read the ip address to add to outer IP > header , as per my knowledge it > should be from sa policy. Please correct me Yes, from the SPD. For tunnel mode you have the source and destination netmasks which get encapsulated inside ESP or AH, and additionally the end-point addresses which are the outer IP header addresses. You probably need to update the SPD rule dynamically when your public IP changes. - Timo |
From: Naveen BN <nav...@gl...> - 2009-12-28 08:16:04
|
Timo, Tls can provide client to site solution ( VPN solution) and It is no problems even in the presence of NAT nor the overhead of NAT keep alive. For the end user the configuration of Ipsec policies is also an overhead . Regards Naveen Timo Teräs wrote: > Hi, > > You should really post on the list. > > Naveen BN wrote: >> Has i am working on ipsec key management application using xfrm, i am >> interested to know the *future of >> IPsec and it's job market*, because TLS has more advantages when >> compared to Ipsec. > > I am no prophet to know about the future. Both have their advantages > and they target a bit different use case. > > TLS is TCP-based and not suited really for VoIP or any other UDP-based > program. TCP-inside-TCP tunneling is also bad. So TLS is good only for > application level stuff. So if you are good with running https, sips > etc. then you are ok with TLS. > > IPsec is a layer 2 transport. And does it job at very low level. > Any application that is not TLS aware, can be secured with it. It works > good with any protocol. It also is typically faster as IPsec part of > the protocol is done in kernel mode (only IKE runs in userland). This > results in lower hardware requirements. > > - Timo > |
From: Timo T. <tim...@ik...> - 2009-12-28 08:31:07
|
Naveen BN wrote: > Tls can provide client to site solution ( VPN solution) and It is no > problems even in the presence of NAT nor the overhead of NAT keep alive. > For the end user the configuration of Ipsec policies is also an overhead . 1. TLS != VPN solution. There are *TLS-based* VPN solutions such as OpenVPN, but TLS in itself is an application level protocol. 2. TLS does have NAT keep-alive in form of TCP-keepalive, or if running over UDP it needs an application level keep-alive mechanism (see e.g. OpenVPN --keepalive option). 3. Proper TLS based solution requires also configuration. For clear server-client installs, you should be using autogenerated IPsec policies. Which one is easier depends on which one you know better ;) >> TLS is TCP-based and not suited really for VoIP or any other UDP-based >> program. TCP-inside-TCP tunneling is also bad. So TLS is good only for >> application level stuff. So if you are good with running https, sips >> etc. then you are ok with TLS. Oh, OpenVPN does have UDP mode so it's not strictly like this, but you do need to be careful on choosing how the protocols are stacked. >> IPsec is a layer 2 transport. And does it job at very low level. >> Any application that is not TLS aware, can be secured with it. It works >> good with any protocol. It also is typically faster as IPsec part of >> the protocol is done in kernel mode (only IKE runs in userland). This >> results in lower hardware requirements. This applies. Please read the basics how the two protocols differ. Start with: http://en.wikipedia.org/wiki/Transport_Layer_Security http://en.wikipedia.org/wiki/IPsec These two protocols work in separate layer of TCP/IP stack. They have separate use cases. Short guide to choose is: - If you want to combine networks: use IPsec - If you want to provide secure services or connect one computer to centralized place: use TLS - Timo |