[Openswan Users] Forcing port 4500

Mon Feb 14 09:08:02 EST 2011

Roel,
Add a feather to your cap, that idea worked!! Thank you!
Now on to testing the remaining issues/configurations, those mainly dealing with NAT and Windows2003 interactions.

Patrick Swartz
UNIX Planning & Engineering (DSUSSE)
First Data 
402-777-7337 desk
402-201-1192 Company cell
402-871-8981 Personal cell

-----Original Message-----
From: Roel van Meer [mailto:rolek at bokxing.nl] 
Sent: Monday, February 14, 2011 12:40 AM
To: Swartz, Patrick H
Cc: users at openswan.org
Subject: Re: [Openswan Users] Forcing port 4500

Swartz, Patrick H writes:

> Doesn't seem to matter --
> 
> sending 592 bytes for EVENT_RETRANSMIT through eth0:4600 to 167.16.139.24:500 (using #1)
> 
> Looks like it is still trying to connect on the right side on port 500.  
> Is there a way to tell pluto on the right side to listen on port 4600 (or 
> whatever port)?

Perhaps you can use iptables to accomplish this?

iptables -t nat -A OUTPUT -o eth0 -d <peerip> -p udp --dport 500 -j DNAT --to-destination <peerip>:4500
iptables -t nat -A PREROUTING -i eth0 -s <peerip> -p udp --dport 4500 -j REDIRECT --to-port 500

If you run these two commands on both of your servers, you can keep your 
original ipsec config (without --ikeport 4500) but traffic will be sent via 
port 4500 anyhow.

You'll have to adjust the device and <peerip> for your setup, of course.

I've never used this trick with ipsec, so I'm not entirely sure this 
works, but it should. I've used it with SIP, when we had routers that tried 
to do NAT on the default si pports and broke it horribly in the process. 

Good luck,

Regards,

Roel

> Patrick Swartz
> UNIX Planning & Engineering (DSUSSE)
> First Data 
> 402-777-7337 desk
> 402-201-1192 Company cell
> 402-871-8981 Personal cell
> 
> 
> -----Original Message-----
> From: Paul Wouters [mailto:paul at xelerance.com] 
> Sent: Sunday, February 13, 2011 12:13 PM
> To: Swartz, Patrick H
> Cc: users at openswan.org
> Subject: RE: [Openswan Users] Forcing port 4500
> 
> On Sat, 12 Feb 2011, Swartz, Patrick H wrote:
> 
>> Hi,
>> Thanks for the quick reply !!
>>
>> Well, adding that to the ipsec.conf file did the trick so far as setting the outgoing port to 4500.  However, it didn't work as I expected.
>> I set that on both sides, but after restarting and sending a test ping I see this in both secure logs --
> 
> Did you try what i said:
> 
>  	You might need to pick something other then 4500 to not interfere with the "jumping to 4500" though.
> 
> Paul
> 
>> [Left log]
>> Feb 12 01:13:05 r9tvmp502 pluto[20492]: | handling event EVENT_RETRANSMIT for <invalid> "r9tvmp502-jerry" #1
>> Feb 12 01:13:05 r9tvmp502 pluto[20492]: | sending 592 bytes for EVENT_RETRANSMIT through eth0:4500 to 167.16.139.24:500 (using #1)
>>
>> [Right log]
>> Feb 12 14:20:59 rhel5-3atest pluto[25332]: "r9tvmp502-jerry" #2: initiating Main Mode to replace #1
>> Feb 12 14:20:59 rhel5-3atest pluto[25332]: | sending 592 bytes for main_outI1 through eth0:4500 to 167.16.146.13:500 (using #2)
>>
>>
>> The brass-tax of this is I just need to work around our firewalls that are blocking port 500.
>>
>> Here is a diagram of the test environment --
>> [left side] r9tvmp502(167.16.146.13) --> jerry(167.16.139.24) [right side]
>>
>>
>> Here is the main ipsec.conf that is the same on both sides --
>> version 2.0     # conforms to second version of ipsec.conf specification
>>
>> # basic configuration
>> config setup
>>        # Debug-logging controls:  "none" for (almost) none, "all" for lots.
>>        # klipsdebug=none
>>        plutodebug="control parsing"
>>        plutoopts="--ikeport 4500"
>>        # For Red Hat Enterprise Linux and Fedora, leave protostack=netkey
>>        protostack=netkey
>>        nat_traversal=yes
>>        virtual_private=
>>        oe=off
>>        # Enable this if you see "failed to find any available worker"
>>        nhelpers=0
>>
>> And the conn
>> conn r9tvmp502-jerry
>>        connaddrfamily=ipv4
>>        type=tunnel
>>        authby=secret
>>        left=167.16.146.13
>>        right=167.16.139.24
>>        esp=3des
>>        keyexchange=ike
>>        pfs=no
>>        auto=start
>>        forceencaps=yes
>>
>> Patrick Swartz
>> UNIX Planning & Engineering (DSUSSE)
>> First Data
>> 402-777-7337 desk
>> 402-201-1192 Company cell
>> 402-871-8981 Personal cell
>>
>> -----Original Message-----
>> From: Paul Wouters [mailto:paul at xelerance.com]
>> Sent: Saturday, February 12, 2011 12:10 PM
>> To: Swartz, Patrick H
>> Cc: users at openswan.org
>> Subject: Re: [Openswan Users] Forcing port 4500
>>
>> On Sat, 12 Feb 2011, Swartz, Patrick H wrote:
>>
>>> After much trial-and-error, I think I have found the culprit “ we have firewalls that are blocking port 500.  However, port 4500 is open.
>>> So my questions is “ Can I force openswan to use port 4500 for everything?
>>>
>>> I have set  --œ forceencaps=yes  “ in the conn section of the openswan.conf file and œ nat_traversal=yes  even though I™m not using
>>> NAT™ing just yet.
>>>
>>> However, after watching the /var/log/secure it looks like packets are still being sent out on port 500.
>>
>> The first packet still goes out over port 500.
>>
>> You can try adding this to config setup in ipsec.conf:
>>
>> 	plutoopts="--ikeport 4500"
>>
>> You might need to pick something other then 4500 to not interfere with the "jumping to 4500" though.
>>
>> Let us know how this goes,
>>
>> Paul
>>
>>
>> -----------------------------------------
>> The information in this message may be proprietary and/or
>> confidential, and protected from disclosure.  If the reader of this
>> message is not the intended recipient, or an employee or agent
>> responsible for delivering this message to the intended recipient,
>> you are hereby notified that any dissemination, distribution or
>> copying of this communication is strictly prohibited. If you have
>> received this communication in error, please notify First Data
>> immediately by replying to this message and deleting it from your
>> computer.
> _______________________________________________
> Users at openswan.org
> http://lists.openswan.org/mailman/listinfo/users
> Micropayments: https://flattr.com/thing/38387/IPsec-for-Linux-made-easy
> Building and Integrating Virtual Private Networks with Openswan: 
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155