[Openswan Users] Forcing port 4500
paul at xelerance.com
Sun Feb 13 20:47:36 EST 2011
On Sun, 13 Feb 2011, Swartz, Patrick H wrote:
> Doesn't seem to matter --
> sending 592 bytes for EVENT_RETRANSMIT through eth0:4600 to 22.214.171.124: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
> 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:
>> 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.
>> [Left log]
>> Feb 12 01:13:05 r9tvmp502 pluto: | handling event EVENT_RETRANSMIT for <invalid> "r9tvmp502-jerry" #1
>> Feb 12 01:13:05 r9tvmp502 pluto: | sending 592 bytes for EVENT_RETRANSMIT through eth0:4500 to 126.96.36.199:500 (using #1)
>> [Right log]
>> Feb 12 14:20:59 rhel5-3atest pluto: "r9tvmp502-jerry" #2: initiating Main Mode to replace #1
>> Feb 12 14:20:59 rhel5-3atest pluto: | sending 592 bytes for main_outI1 through eth0:4500 to 188.8.131.52: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(184.108.40.206) --> jerry(220.127.116.11) [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
>> # Enable this if you see "failed to find any available worker"
>> And the conn
>> conn r9tvmp502-jerry
>> 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,
>> 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
More information about the Users