[Openswan Users] Forcing port 4500

[Swartz, Patrick H]

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

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.