[Openswan Users] Forcing port 4500

[Paul Wouters]

On Sun, 13 Feb 2011, Swartz, Patrick H wrote:

> 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)?

Ahh. I see now on the man page for ipsec_pluto that the --ike-port is "per endpoint". But
this is part to specify in the config file. I will change this in a future version
to allow specifying the other endpoint as well. For now, your best bet is to change

[root at bofh ]$ grep 500 openswan.git/include/*
ietf_constants.h:#define IKE_UDP_PORT	500

Paul


> 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.
>