Nsis_Imp December 2006

nsis_imp@informatik.uni-goettingen.de

8 participants
18 discussions

nsis-qos
by Jesús Pérez 31 Dec '06

31 Dec '06

Hello, I have some problems to run the QoS implementation of the developer version from 10th of November. I am using 2 computers as QNI and QNR without any other QNE between them. I have added the outputs from the different consoles below. First of all, I run the nsis and it works well because I have used the nsis-ping to test it. Then, I run nsis-qos daemon and the client is connected to the QoS server. However, when I finally send a nsis-qos reservation to the 192.168.1.103 <http://192.168.1.103> (QNR) from 192.168.1.102 <http://192.168.1.102> (QNI), the QoS server seems to be deleted and the nsis connection is reset. If anyone knows why this happens, I would appreciate your help. QNI : ------------------------------------------------------ /nsis (err) Using 192.168.1.102 <http://192.168.1.102> as local IPv4 address NSIS daemon v0.5.0-dev starting ... My PID id = 20424 FD is -1 TEST: no Starting pingServer (pid: 20425) ... Ping client connected *** Unix Socket: Connection reset by peer *** ------------------------------------------------------- ------------------------------------------------------- ./nsis-qosd -level 6 (err) Using 192.168.1.102 <http://192.168.1.102> as local IPv4 address (TC) Running "tc qdisc delete dev eth1 root handle 1:" (IpTables) Running "iptables -t mangle -F PREROUTING" (TC) Running "tc qdisc add dev eth1 root handle 1: htb default 2" (TC) Running "tc class add dev eth1 parent 1: classid 1:1 htb rate 100mbit burst 15k" (TC) Running "tc class add dev eth1 parent 1:1 classid 1:2 htb rate 100kbit ceil 100mbit" (TC) Running "tc qdisc add dev eth1 parent 1:2 handle 2: sfq perturb 10" QoSServer: connected to GIST server QoSServer: client connected SID: ffffffff ffffffff ffffffff ffffffff >-- This is an unknown session!! --< We are End Node (QNI) QNI: --> incoming msg + srcAddr : 192.168.1.102 <http://192.168.1.102> + destAddr : 192.168.1.103 <http://192.168.1.103> + direction : DOWNSTREAM + msg length : 112 bytes + QoS Message Type : RESERVE + Object Type : RII ++ RII : 0x1d98ceca + Object Type : RSN ++ RSN : 1 ++ EpochID : 0x45926521 + Object Type : PacketClassifier ++ PacketClassifier : 0x00 ++ PC-Flags : 0xc000 + Object Type : Qspec + QSPEC obj length : 19 ++ Qspec Version : 1 ++ QOSM ID : 1 ++ Message Seq. : 1 ++ Obj Combination : 1 +++ Object type : Minimum QoS, length:17 +++ Object type : ExcessTreatment, length:1 +++ M:E:N:R : 0:0:0:0 +++ Excess Treatment: ff +++ Remark Value : ee +++ Object type : Traffic, length:5 +++ M:E:N:R : 0:0:0:0 +++ Bucket Rate : 20.400000 +++ Bucket Size : 1.000000 +++ Peak Rate : 2.000000 +++ min Unit : 3 +++ MTU : 4 +++ Object type : QoSClass, length:3 +++ M:E:N:R : 0:0:0:0 +++ DSCP : 3f +++ DSTE : aa +++ Y.1541 : aa +++ Object type : Priority, length:4 +++ M:E:N:R : 0:0:0:0 +++ Preemption P. : 0001 +++ Defending P. : 0002 +++ Admission P. : 0003 +++ RPH Namespace : 0004 +++ RPH Priority : 0005 + Q:T:R:S-Flag : 1:0:0:0 triggerEvent : ST_IDLE::EV_TG_RESERVE QoSFsm::idle__tg_reserve() QoSFsm::tg_reserve() RMF available RR requested:0x04 Reserving ... clean exit: SIGSEGV QoSServer::~QoSServer QoSServer deleted! ------------------------------------------------------------- ------------------------------------------------------------- /nsis-qos 192.168.1.103 <http://192.168.1.103> addr:192.168.1.103 <http://192.168.1.103> Command : RESERVE Q-Flag : 1 T-Flag : 0 R-Flag : 0 S-Flag : 0 Objects : RII RSN PC QSPEC SID : ffffffff ffffffff ffffffff ffffffff terminate called after throwing an instance of 'std::runtime_error' what(): Success Aborted ------------------------------------------------------------- The output of the QNR doesn't change at sending the reservation from the QNI, so I have not included it. Cheers, Jesus

3 2

NATFW createPinhole comments
by sergiole＠tml.hut.fi 29 Dec '06

29 Dec '06

Just to close the thread I let you know the following. About > I am fully aware of the situation, but an NSIS signaling session > relates to an uni-directional flow. > That means: just one direction. So to install FW rules for both > directions you will need two NSIS signaling session. Yes you are right. I am sorry for all the comments out of place in some messages in this thread. Anyway, perhaps if I let you know the following you will understand my situation and maybe I can help indirectly by presenting a case that is not very clear in the specifications. The questions are not directed to you, these are what I am asking to myself; but anyway, if you have some comments, these are welcome. Below when I mention NF I try to cover a chain of several NF with FW, but actually my implementation is considering the following scenario (only one NF with FW) NI<--------->NF(FW) We are using the proxy mode that consist of a NI and several NF (no NR at the end of the path). In particular, only one NF in our case. NI---------NF---------NF---------NF---------NF As far as I understand, since there is not NR at the end of the path (and therefore this NR can not become NI+), the last NF in the path becomes a NI+ that will create a session in the opposite direction. NI<---------------NF [NI+] When the last NF (now NI+) creates a session in the opposite direction; should it start by creating a session into itself? In other words, if the last NF (working as NI+) does not open his own FW (by sending a create to itself), then no traffic will be able to go through the FW in the last NF. In our case we have only one NF, and it is the last NSIS node in the path. Then I think that it must create a session into itself and open the FW in the inverse direction. NI<---------------NF [NI+] ----\ ^ | | | CREATE \------------/ My implementation needs to open the FW in the inverse direction at the same time that I open the FW for the forward direction. As far as I understand it should be done as mentioned above, i.e. using a NSIS CREATE (a packet with a create) sent from the NI+ to the NF (to itself in this case). Sergio

1 0

NATFW some comments
by sergiole＠tml.hut.fi 29 Dec '06

29 Dec '06

Hi, 1. { > In NI I was using nsis050old. > In NF I was using nsis050new, except the directory natfw that was > replaced by natfw directory of nsis050old. So did you modify the NSLP IDs so that the two versions are compatible? } I am sorry, I forgot to mention that I used the file NatFwFsm.h from nsis050new . ( It does not contain the line #define NATFW_NSLP_ID 3 and I avoided some problems.) After I realized that there are two nsis050dev releases I continued my tests using nsis050old. I am no longer testing with nsis050new and probably I am not going to use this code since my implementation is based in nsis050old and I have no time to re-arrange my code to the new version. 2. { The only reason for this I can think of is NSLP ID related. Your linux box uses NSLP ID 3 for NATFW, but the OpenWRT uses ID 1 for NATFW and ID 3 for Ping. Thus, GIST forwards the message to the Ping NSLP instead of NATFW. Please check library/NslpIDs.h } My nsis050old library/NslpIDs.h conatins #define PING_NSLP_ID 3 #define NATFW_NSLP_ID 2 #define QOS_NSLP_ID 1 #define DIAGNOSTICS_NSLP_ID 5 Sergio

1 0

NATFW some comments
by sergiole＠tml.hut.fi 28 Dec '06

28 Dec '06

Hi, I. Details I was using a nsis-0.5.0-dev.tar.gz version that I downloaded around 2006-11-07. Let me call it nsis050old. (I can sent it, if you want). The new version that I used was downloaded yesterday. Let me call it nsis050new. My scenario is NI 192.168.1.2 (Linux) ---------------- NF 192.168.1.1 (openWrt) In NI I was using nsis050old. In NF I was using nsis050new, except the directory natfw that was replaced by natfw directory of nsis050old. II. About { > I do not know how related are ping to NATFW projects. I could not > use ping, with your last release (mixed with NATFW directory). They are not related at all, except for the fact that both use the NSLP API. Can you explain the problem with ping? } I said "I do not know how related are ping to NATFW projects" , because: I ran nsis-natfw at the NI and at the NF I got the following. Note *** GistException: Invalid ping message. Length invalid *** at the end.: root@OpenWrt:/home# nsis -debug 0 (err) Using 192.168.1.1 as local IPv4 address (err) Using 192.168.2.1 as local IPv4 address (err) Setting Debug Level to 0 NSIS daemon v0.5.0-dev starting ... My PID id = 2511 FD is -1 TEST: no Starting pingServer (pid: 2512) ... Starting natfwServer (pid: 2513) ... (info) NSIS NAT/Firewall NSLP daemon starting... (info) (NatFw) Router: yes (info) (NatFw) Edge-Router: yes (info) (NatFw) NAT: no (info) (NatFw) Firewall: yes (info) (NatFw) external IP addr: 192.168.2.1 (info) (NatFw) router is a Firewall! (TBD) Socket 4 has new data (warn) *** Connection over Unix Socket *** (warn) register_unix_sd : new connection sd[8] added to Event Loop. (TBD) Socket 8 has new data (warn) *** Received API Call *** (info) (NatFw) createServerSocket (TBD) Socket 4 has new data (warn) *** Connection over Unix Socket *** (warn) register_unix_sd : new connection sd[9] added to Event Loop. (TBD) Socket 9 has new data (warn) *** Received API Call *** (info) (NatFw) connected to GIST server (TBD) Socket 5 has new data (warn) *** Received RAO packet (value = 00 00) *** (warn) *** Dmode message from : 192.168.1.2:33294> *** (info) GIST message: Version = 1 hops = 4 Signaling Application ID = 3 Message length = 144 (info) Type = QUERY (info) S flag = 0 (info) R flag = 1 (info) GistMriPathCoupled: length = 56 (info) Direction = Downstream (info) Source IP = 192.168.1.2 (info) Dest IP = 130.233.240.9 (info) Source Port = 0 (info) Destination Port = 0 (info) GistSessionId: length = 20 (info) (info) cc (info) 41 (info) 99 (info) 75 (info) c2 (info) 7d (info) 76 (info) 1f (info) 0e (info) 2b (info) c2 (info) ee (info) f0 (info) 67 (info) 9a (info) 2f (info) (info) GistNetworkLayerInfo: length = 28 (info) IntAddr = 192.168.1.2 (info) RouteStateValidityTime = 180000 (info) GistQueryCookie: length = 36 (info) GistStackProposal: length = 12; profileCount = 1 (info) Profile 1: (info) TCP (info) (info) GistStackConfigurationData: length = 16 (warn) *** This is a UNknown flow *** (info) FSM: Change state to 0 (info) FSM: Event 5 while state is 0 (warn) Creating new MA (warn) register_server_sd : new connection sd[10] added to Event Loop. (info) FSM: Change state to 1 (TBD) Socket 10 has new data (warn) Found the pending MA (warn) *** Cmode connect via IPv4 from : 192.168.1.2:34035 *** (warn) register_sd : new connection sd[11] added to Event Loop. (TBD) Socket 11 has new data (info) GIST message: Version = 1 hops = 4 Signaling Application ID = 3 Message length = 116 (info) Type = CONFIRM (info) S flag = 1 (info) R flag = 0 (info) GistMriPathCoupled: length = 56 (info) Direction = Downstream (info) Source IP = 192.168.1.2 (info) Dest IP = 130.233.240.9 (info) Source Port = 0 (info) Destination Port = 0 (info) GistSessionId: length = 20 (info) (info) cc (info) 41 (info) 99 (info) 75 (info) c2 (info) 7d (info) 76 (info) 1f (info) 0e (info) 2b (info) c2 (info) ee (info) f0 (info) 67 (info) 9a (info) 2f (info) (info) GistNetworkLayerInfo: length = 28 (info) IntAddr = 192.168.1.2 (info) RouteStateValidityTime = 180000 (info) GistResponderCookie: length = 36 (warn) *** This is a known flow *** (info) FSM: Event 9 while state is 1 (info) FSM: Change state to 4 (info) GIST message: Version = 1 hops = 4 Signaling Application ID = 3 Message length = 108 (info) Type = DATA (info) S flag = 0 (info) R flag = 0 (info) GistMriPathCoupled: length = 56 (info) Direction = Downstream (info) Source IP = 192.168.1.2 (info) Dest IP = 130.233.240.9 (info) Source Port = 0 (info) Destination Port = 0 (info) GistSessionId: length = 20 (info) (info) cc (info) 41 (info) 99 (info) 75 (info) c2 (info) 7d (info) 76 (info) 1f (info) 0e (info) 2b (info) c2 (info) ee (info) f0 (info) 67 (info) 9a (info) 2f (info) (info) GistNetworkLayerInfo: length = 24 (info) IntAddr = 192.168.1.2 (info) RouteStateValidityTime = 180000 (info) GistNslpData: length = 32; payloadLength = 28 (warn) *** This is a known flow *** (info) FSM: Event 11 while state is 4 (info) *** API-Call RecvMessage() *** (info) nslp_data : (info) nd_size : 28 (info) nslp_id : 0x0003 (info) sid : (info) 0xcc (info) 0x41 (info) 0x99 (info) 0x75 (info) 0xc2 (info) 0x7d (info) 0x76 (info) 0x1f (info) 0x0e (info) 0x2b (info) 0xc2 (info) 0xee (info) 0xf0 (info) 0x67 (info) 0x9a (info) 0x2f (info) (info) mri->msgRoutingMethod : 0x0000 (info) mri->s : 0 (info) mri->f : 0 (info) mri->t : 0 (info) mri->p : 1 (info) mri->ipVersion : 0x04 (info) mri->reserved : 0x00 (info) mri->d : 0 (info) mri->b : 1 (info) mri->a : 1 (info) mri->srcAddr : 192.168.1.2 (info) mri->destAddr : 130.233.240.9 (info) mri->srcPrefix : 0x20 (info) mri->destPrefix : 0x20 (info) mri->protocol : 0x00 (info) mri->diffserv_field : 0x00 (info) reliable : 1 (info) security : 0 (info) explicitlyRouted : 0 (info) noGistState : 0 (info) ip_ttl : 0 (info) ip_distance : 0 DataSize: 28, HeaderLength: 0, Calc: 3076(crit) *** GistException: Invalid ping message. Length invalid *** (info) (NatFw) GenericObject::count: 0 (info) (NatFw) NatBinding::count: 0 (info) (NatFw) FwPinhole::count: 0 -- Note: I changed NatFwFsm::nf_rx_create() code. I removed all the NAT handling and added the following (borrowed from NatFwFsm::nf_waitresp_rx_response() ) in an attempt to implement the proxy mode (without NR case) NatFwMessage responseMessage(NATFW_MESSAGETYPE_RESPONSE); responseMessage.addSessionLifetimeObject(new NatFwSessionLifetimeObject(1000)); responseMessage.addMsnObject(new NatFwMsnObject(recvMessage.msn->value())); responseMessage.addInformationCodeObject(new NatFwInformationCodeObject( NATFW_CLASS_SUCCESS, NATFW_CODE_SUCCESS_ALL, NATFW_MESSAGETYPE_CREATE)); printf("-*-*- 2 \n"); msg_routing_info_path_coupled_t pc_mri; pc_mri.msgRoutingMethod = GIST_DEFAULT_MRM; pc_mri.ipVersion = 4; pc_mri.srcAddr.v4.addr = data->recv_msg->mri->srcAddr.v4.addr; pc_mri.destAddr.v4.addr = data->recv_msg->mri->destAddr.v4.addr; pc_mri.srcPrefix = 32; pc_mri.destPrefix = 32; pc_mri.d = UPSTREAM; pc_mri.flowLabel = 0; pc_mri.destPort = 0; pc_mri.srcPort = 0; pc_mri.spi = 0; III. About { > Also I noticed some strange behavior with calls to > data->server->SendMessage() from my old NATFW to the new 0.5.0-dev > code, (like Queries instead of responses ). Could you explain this in more detail? } In this case, I have the implementation in NatFwFsm::nf_rx_create() mentioned above. When I use my nsis050old at both sides, the code above sends the RESPONSE message correctly. When I mix the code as explained, I do not get a RESPONSE (what the code above is supposed to do) but I see en ethereal a GIST QUERY from NF to NI instead of a RESPONSE. (I do not know who is triggering it). Anyway, if your nsis050new is working properly I think that is not worth to spent time with a result of a mixed code... All the above was tested with openWrt at the NF. It should be the same behavior with Linux... Sergio.

2 1

[Fwd: Re: [Nsis_imp] nsis-qos]
by Christian Dickmann 28 Dec '06

28 Dec '06

Hi, Bernd: Any idea? -------- Original-Nachricht -------- Betreff: Re: [Nsis_imp] nsis-qos Datum: Thu, 28 Dec 2006 13:48:56 +0100 Von: Jesús Pérez <jesus(a)tlmat.unican.es> An: Christian Dickmann <mail(a)christian-dickmann.de> Referenzen: <4592B368.6050408(a)tlmat.unican.es> <4593062F.7050303(a)christian-dickmann.de> Christian Dickmann wrote: > Hi, > > I am not an expert on the QoS NSLP, so my comments are rather general. > However, I hope I can help you. > >> >> clean exit: SIGSEGV >> QoSServer::~QoSServer >> QoSServer deleted! > > > The QoS NSLP daemon gets a SEGFAULT signal and shuts down as a result. > This means: The daemon crashed! > You should run it using GDB to see where the SEGFAULT is thrown and > provide us with a backtrace (command "bt" in GDB). > > I hope Bernd can help you debugging your problem when he gets the > backtrace. Without the backtrace it is probably very hard to tell > whats going wrong. > > Thank you for your help. > > Regards, > Christian > Hi, Here is the bt output you asked me for: #0 0x0805af33 in Traffic::bandwidth (this=0x838c668) at qspec/Traffic.cpp:86 #1 0x0805bd6e in SimpleRMF::reserveQoS (this=0x834c0a0, mri=0x838b540, desired_qspec=0x838c5c8, sid=0x838b50c '%GÃ¯Â¿Â½%@' <repeats 16 times>, bound_sid=0x838b52c "", reserv_qspec=0x0, newNslpId=0x838b4fc, rmfData=0x838b4c0) at rmf/SimpleRMF.cpp:85 #2 0x0804f1a1 in QoSFsm::tg_reserve (this=0x838b488, event=5, args=0x838b4c0) at fsm/QoSFsm.cpp:503 #3 0x0804e705 in QoSFsm::triggerEvent (this=0x838b488, event=EV_TG_RESERVE, args=0x838b4c0) at fsm/QoSFsm.cpp:216 #4 0x0804c704 in QoSServer::handleClientSocket (this=0x834c028, sockfd=8, sockData=0x838b410) at QoSServer.cpp:572 #5 0x0806329c in NslpApi::processSockets (this=0x834c148, rfds=0xbfd2627c) at NslpApi.cpp:166 #6 0x080634bc in NslpApi::waitForSignal (this=0x834c148) at NslpApi.cpp:206 #7 0x0804a58d in QoSServer::run (this=0x834c028) at QoSServer.cpp:97 #8 0x08049d0c in main (argc=1, argv=0xbfd26414) at qos_server.cpp:110 I hope it can help you. Thank you. Cheers, Jesus

2 1

NATFW some comments
by sergiole＠tml.hut.fi 28 Dec '06

28 Dec '06

Hello, If you think that you saw some errors like the following ones, it will be helpful to know more about. I am trying to track some problems that appear only in openWrt and I could not reproduce in Linux, so it is very difficult to find a solution. 1) I have some problems with the ping utility when I run it in a openWrt package that I created from the sources in nsis-0.5.0-dev.tar.gz . At the moment I created several packages with minor problems but only tested NATFW. Surprisingly if I use the package that is available in your pages (nsis_0.5.0-dev-1_mipsel.ipk) everything seems to be OK. Did you use nsis-0.5.0-dev.tar.gz to create your package or other sources? 2) with ping I get the following (warn) *** Received RAO packet (value = 00 00) *** (warn) *** Dmode message from : 192.168.1.2:33295> *** (warn) *** NSLP Id or MRM not supported and we are endhost, so drop it (NSLP ID = 1)*** 3) Also I do not know why I have the following line of code #define NATFW_NSLP_ID 3 in some old files NatFwFsm.cpp. In the distribution nsis-0.5.0-dev.tar.gz the above is no longer in the file, but it seems that it was in a earlier nsis-0.5.0-dev.tar.gz file (?) . If you did not change your distribution files I am not sure from where I got that file... If I use it I get an error like root@OpenWrt:/home# nsis (err) Using 192.168.1.1 as local IPv4 address (err) Using 192.168.2.1 as local IPv4 address NSIS daemon v0.5.0-dev starting ... My PID id = 1246 FD is -1 TEST: no Starting pingServer (pid: 1247) ... Starting natfwServer (pid: 1248) ... Starting diagServer (pid: 1249) ... (err) Diag: connected to GIST server (crit) *** GistException: NSLP ID already registered *** I discovered this behavior with openWrt; with Linux there is not problem... 4) Is the ping associated to NATFW code? As mentioned above, ping is not working in my openWrt package, but in this case I am testing NATFW. When the the NF sends a response I get in the logs DataSize: 28, HeaderLength: 0, Calc: 3076(crit) *** GistException: Invalid ping message. Length invalid *** Any comments are welcome, it takes very time to create and upload the packages so it is very difficult to debug in openWrt Regards, Sergio

2 3

NATFW createPinhole comments
by sergiole＠tml.hut.fi 20 Dec '06

20 Dec '06

Hi, I am confused with my comments about point 3) in my previous email. And I not sure if your answer relates to my question. . I said: (the complete part is attached at the end) >> (Remember that my default policy is deny-all.) then at the FW I >> need NOT 1 but 2 rules !! , i.e.: >> >> Rule 1) Allow traffic from 10.1.1.5 -port 5000 to 10.1.2.11-port 80 >> >> and >> >> Rule 2) Allow traffic from 10.1.2.11-port 80 to 10.1.1.5 -port 5000 >> >> >> Otherwise (with only 1 rule) the FW will filter the traffic in one >> or other direction. The main doubt is about a) "configuring a path downstream" in NATFW specification means "NSIS is downstream but associated traffic can be in any direction over the path" against b) "configuring a path downstream" in NATFW specification means "NSIS is downstream AND associated traffic is only in downstream direction over the path too" I think that your answer > NSIS signaling (and thus the meaning on the NSLP layer) is > uni-directional. is OK in NSIS context, but what I am looking for is to decide if the implementation at 'iptables' level is OK or not. Example: I connect to a WWW server with my browser. The traffic is 1) MyPC--->WWWserver - I send a TCP SYN packet to the destination, 2) WWWserver <---MyPC - destination sends back SYN+ACK 3) MyPC--->WWWserver - I reply with an ACK. Note that there is a traffic from/to MyPC to/from WWWserver. Now suppose that I want to open a firewall using NSIS to allow my connection. In practice we need 2 entries in IPTABLES 1) One entry to allow MyPC--->WWWserver direction 2) Another entry to allow WWWserver <---MyPC direction This is because in iptables we configure FROM IP/port TO IP/port. Therefore we need 2 rules. Example: MyPC : IP 200.233.16.6 port 4000 WWWserver : IP 200.233.228.9 port 80 rule 1: FROM 200.233.16.6 ( 4000 ) TO 200.233.228.9 ( 80 ) ; SYN case, ACK case rule 2: FROM 200.233.228.9 ( 80 ) TO 200.233.16.6 ( 4000 ) ; SYN+ACK case So, about this was my question : We need 2 entries in IP tables (traffic that go and that return). This thread comes about that you are using only one call to iptables, and it is working because you have an allow all policy thus you can not notice any strange. In my case I have a deny-all policy, so, if I do not add the second entry in iptables I will never receive the SYN+ACK. Then in createPinhole() (assume an allow-all policy) For example, I think that you need to add an additional line after else if (ruleaction == 2){ sprintf(buf, "iptables -A natfwforward -p tcp -s %s/%d --sport %d -d %s/%d --dport %d -j DROP ", saddrbuf, srcPrefix, srcPort, daddrbuf, destPrefix, destPort); for example something like sprintf(buf, "iptables -A natfwforward -p tcp -s %s/%d --sport %d -d %s/%d --dport %d -j DROP ", daddrbuf, destPrefix, destPort saddrbuf, srcPrefix, srcPort, ); Note the switch between origin/destination IPs/ports Regards, Sergio >> 3) >> (Remember that my default policy is deny-all.) then at the FW I >> need NOT 1 but 2 rules !! , i.e.: >> >> Rule 1) Allow traffic from 10.1.1.5 -port 5000 to 10.1.2.11-port 80 >> >> and >> >> Rule 2) Allow traffic from 10.1.2.11-port 80 to 10.1.1.5 -port 5000 >> >> >> Otherwise (with only 1 rule) the FW will filter the traffic in one >> or other direction. >> >> >> Do you agree? Comments? >> >> >> My question is : >> >> 1) Should I use 1 time nsis-natfw and open the traffic for both >> sides (i.e. 2 calls to Iptables in createPinhole())? >> >> or >> >> 2) Should I use 2 times nsis-natfw and open the traffic for one >> direction per execution? >> >> >> (I think that the the correct answer is 1, otherwise, how should >> be the MRI in case 2...) > > NSIS signaling (and thus the meaning on the NSLP layer) is > uni-directional. Thus you are right, that one signaling session will > only open one direction. You will have to initiate NSIS signaling from > both sides (!) to open the pin hole if your data is bi-directional. > So the correct answer is your case 2 and the MRI is straight forward. A > bi-directional flow is just a set of 2 uni-directional flows > and so you need 2 NSIS sessions and the corresponding MRIs are just as > usual. In your example: > You run the NATFW client on 10.1.1.5 with MRI set to (10.1.1.5 -port > 5000 to 10.1.2.11-port 80) and > you run the NATFW client on 10.1.2.11 with MRI set to (10.1.2.11-port > 80 to 10.1.1.5 -port 5000). > > Henning: Is this correct for the NATFW NSLP? >

3 4

NATFW createPinhole comments
by sergiole＠tml.hut.fi 19 Dec '06

19 Dec '06

Hi, 1) >> - With deny policy in the EFI : Add a DENY rule >> - With allow policy in the EFI : Remove the previous DENY rule > The question is in the second case (allow-all policy, but allow in > EFI): Who created the previous DENY rule? > If the NATFW NSLP created it, then you should NOT remove this > previous rule, because it will be removed by > terminating the corresponding signaling session. I was thinking to close the signaling session (time out not assumed) by explicitly removing the rule that was created. I can not find another way to close it in NATFW specification. Is there some method to do it at GIST level? For example if I created a deny rule, then by removing it should I close the session? In your implementation (NatFwFsm.cpp) a rule is removed only if zero-lifetime is true. So it seems that you consider removing a rule only in the case that the session lifetime is zero. 2) >> 2) >> >> About EFI Object and sub_ports field. >> >> sub_ports field is a number that is added to the port number to >> define a range of ports. >> In draft-ietf-nsis-nslp-natfw-13.txt the draft states that >> sub_ports must not be other value than 0 and 1. Nevertheless it >> could be handy to use any number and then use it to implement a >> port range in iptables when crating a FW rule.... > Well, that is nothing we can decide. The authors of the draft have > their reasons to limit the valid values to 0 and 1 and thus we > should honor there decision. Ok. My suggestion is mainly for testing, not to extend the protocol or go against. It is handy to take the opportunity that the field could be available and use any number. And then define a set of port numbers like 1024:65535 with Iptables. If you use a web-browser or any other application and you want to do some tests or demo, you will need to know before hand the port number (origin port) that the application is going to use in order to set the FW. In my tests I harcoded the call to Iptables to skip the origin port and use 1024:65536 instead. Otherwise I had to spent more time sending an specific port number as a parameter and I had to tcdump all the time and check the port that is using my application. It could be a transitional solution. As nsis is not integrated to my browser, it could be an approach to introduce nsis without major requirements...(just an opinion). 3) > NSIS signaling (and thus the meaning on the NSLP layer) is > uni-directional. Thus you are right, that one signaling session will > only open one direction. You will have to initiate NSIS signaling > from both sides (!) to open the pin hole if your data is > bi-directional. Ok. I forgot to mention that I am using the proxy mode (NI-NF-NF....NF-NF case , i.e. no NR). As there is not NR in this case. How should be opened the pinholes in the reverse direction? Will the last FW behave as NI and send a CREATE? This case is not very clear in the specification. What my implementation is doing is calling to Iptables 2 times and allow traffic in both directions. I am non sure if my approach is OK. Regards, Sergio

1 0

NATFW CREATE. ICMP Destination unreachable
by sergiole＠tml.hut.fi 19 Dec '06

19 Dec '06

Hello, I have some ICMP packets with the content (Destination unreachable) / (Port unreachable) when I use CREATE in NATFW. Could you suggest if it is a problem of the implementation or configuration? The scenario is DS NI NF NR 10.1.1.5 10.1.1.7 / 10.1.2.7 10.1.2.11 . . . . . . .---------CREATE---------->. . . . . . .---------CREATE---------->. . . . . .<-------RESPONSE----------. .<-------RESPONSE----------. . . . . by using in the NI: ./nsis-natfw --create -s 10.1.1.5 -d 10.1.2.11 --sport 5004 --dport 5019 The flow above is Ok, but I have some ICMP packets with the content (Destination unreachable) / (Port unreachable). Frames 3, 12 and 14 below. Config.ini are as follows { NI Node 10.1.1.5 IPv4[0].addr = 10.1.1.5 IPv4[0].net = 0.0.0.0 IPv4[0].mask = 0 IPv4[0].natfw.useAsExternalAddress = yes IPv4[0].natfw.isPrivateNet = yes natfw.isNAT = no natfw.isFW = no } { NF Node 10.1.1.7 / 10.1.2.7 IPv4[0].addr = 10.1.1.7 IPv4[0].net = 10.1.1.0 IPv4[0].mask = 24 IPv4[0].natfw.useAsExternalAddress = no IPv4[0].natfw.isPrivateNet = yes IPv4[1].addr = 10.1.2.7 IPv4[1].net = 10.1.2.0 IPv4[1].mask = 24 IPv4[1].natfw.useAsExternalAddress = yes IPv4[1].natfw.isPrivateNet = no natfw.isNAT = no natfw.isFW = yes } { NR Node 10.1.2.11 IPv4[0].addr = 10.1.2.11 IPv4[0].net = 0.0.0.0 IPv4[0].mask = 0 IPv4[0].natfw.useAsExternalAddress = yes IPv4[0].natfw.isPrivateNet = no natfw.isNAT = no natfw.isFW = no } Ethereal dump: Frame 1 (190 bytes on wire, 190 bytes captured) Protocols in frame: eth:ip:udp:gist Internet Protocol, Src Addr: 10.1.1.5 (10.1.1.5), Dst Addr: 10.1.2.11 (10.1.2.11) User Datagram Protocol, Src Port: 33113 (33113), Dst Port: 4 (4) General Internet Signaling Transport Signaling Application ID: NAT/FW NSLP (3) Type: Query (0) Frame 2 (226 bytes on wire, 226 bytes captured) Protocols in frame: eth:ip:udp:gist Internet Protocol, Src Addr: 10.1.1.7 (10.1.1.7), Dst Addr: 10.1.1.5 (10.1.1.5) User Datagram Protocol, Src Port: 33086 (33086), Dst Port: 4 (4) General Internet Signaling Transport Signaling Application ID: NAT/FW NSLP (3) Type: response (1) Frame 3 (254 bytes on wire, 254 bytes captured) Protocols in frame: eth:ip:icmp:ip:udp:gist Internet Protocol, Src Addr: 10.1.1.5 (10.1.1.5), Dst Addr: 10.1.1.7 (10.1.1.7) Internet Control Message Protocol Type: 3 (Destination unreachable) Code: 3 (Port unreachable) Checksum: 0x13dc (correct) Internet Protocol, Src Addr: 10.1.1.7 (10.1.1.7), Dst Addr: 10.1.1.5 (10.1.1.5) User Datagram Protocol, Src Port: 33086 (33086), Dst Port: 4 (4) General Internet Signaling Transport Signaling Application ID: NAT/FW NSLP (3) Type: response (1) Frame 7 (182 bytes on wire, 182 bytes captured) Protocols in frame: eth:ip:tcp:gist Internet Protocol, Src Addr: 10.1.1.5 (10.1.1.5), Dst Addr: 10.1.1.7 (10.1.1.7) Transmission Control Protocol, Src Port: 42338 (42338), Dst Port: 32000 (32000), Seq: 1, Ack: 1, Len: 116 General Internet Signaling Transport Signaling Application ID: NAT/FW NSLP (3) Type: Confirm (2) Frame 9 (206 bytes on wire, 206 bytes captured) Protocols in frame: eth:ip:tcp:gist Internet Protocol, Src Addr: 10.1.1.5 (10.1.1.5), Dst Addr: 10.1.1.7 (10.1.1.7) Transmission Control Protocol, Src Port: 42338 (42338), Dst Port: 32000 (32000), Seq: 117, Ack: 1, Len: 140 General Internet Signaling Transport NAT/FW NSLP (NSIS Signaling Layer Protocol) Message Type: CREATE (0x01) Frame 11 (190 bytes on wire, 190 bytes captured) Protocols in frame: eth:ip:udp:gist Internet Protocol, Src Addr: 10.1.2.7 (10.1.2.7), Dst Addr: 10.1.2.11 (10.1.2.11) User Datagram Protocol, Src Port: 33086 (33086), Dst Port: 4 (4) General Internet Signaling Transport Signaling Application ID: NAT/FW NSLP (3) Type: Query (0) Frame 12 (218 bytes on wire, 218 bytes captured) Protocols in frame: eth:ip:icmp:ip:udp:gist Internet Protocol, Src Addr: 10.1.2.11 (10.1.2.11), Dst Addr: 10.1.2.7 (10.1.2.7) Internet Control Message Protocol Type: 3 (Destination unreachable) Code: 3 (Port unreachable) Internet Protocol, Src Addr: 10.1.2.7 (10.1.2.7), Dst Addr: 10.1.2.11 (10.1.2.11) User Datagram Protocol, Src Port: 33086 (33086), Dst Port: 4 (4) General Internet Signaling Transport Signaling Application ID: NAT/FW NSLP (3) Type: Query (0) Frame 13 (226 bytes on wire, 226 bytes captured) Protocols in frame: eth:ip:udp:gist Internet Protocol, Src Addr: 10.1.2.11 (10.1.2.11), Dst Addr: 10.1.2.7 (10.1.2.7) User Datagram Protocol, Src Port: 33062 (33062), Dst Port: 4 (4) General Internet Signaling Transport Signaling Application ID: NAT/FW NSLP (3) Type: Response (1) Frame 14 (254 bytes on wire, 254 bytes captured) Protocols in frame: eth:ip:icmp:ip:udp:gist Internet Protocol, Src Addr: 10.1.2.7 (10.1.2.7), Dst Addr: 10.1.2.11 (10.1.2.11) Internet Control Message Protocol Type: 3 (Destination unreachable) Code: 3 (Port unreachable) Internet Protocol, Src Addr: 10.1.2.11 (10.1.2.11), Dst Addr: 10.1.2.7 (10.1.2.7) User Datagram Protocol, Src Port: 33062 (33062), Dst Port: 4 (4) General Internet Signaling Transport Signaling Application ID: NAT/FW NSLP (3) Type: Response (1) Frame 18 (182 bytes on wire, 182 bytes captured) Protocols in frame: eth:ip:tcp:gist Internet Protocol, Src Addr: 10.1.2.7 (10.1.2.7), Dst Addr: 10.1.2.11 (10.1.2.11) Transmission Control Protocol, Src Port: 34969 (34969), Dst Port: 32000 (32000), Seq: 1, Ack: 1, Len: 116 General Internet Signaling Transport Frame 20 (206 bytes on wire, 206 bytes captured) Protocols in frame: eth:ip:tcp:gist Internet Protocol, Src Addr: 10.1.2.7 (10.1.2.7), Dst Addr: 10.1.2.11 (10.1.2.11) Transmission Control Protocol, Src Port: 34969 (34969), Dst Port: 32000 (32000), Seq: 117, Ack: 1, Len: 140 General Internet Signaling Transport Signaling Application ID: NAT/FW NSLP (3) Type: Data (3) NAT/FW NSLP (NSIS Signaling Layer Protocol) Frame 22 (182 bytes on wire, 182 bytes captured) Protocols in frame: eth:ip:tcp:gist Internet Protocol, Src Addr: 10.1.2.11 (10.1.2.11), Dst Addr: 10.1.2.7 (10.1.2.7) Transmission Control Protocol, Src Port: 32000 (32000), Dst Port: 34969 (34969), Seq: 1, Ack: 257, Len: 116 General Internet Signaling Transport Signaling Application ID: NAT/FW NSLP (3) Type: Data (3) NAT/FW NSLP (NSIS Signaling Layer Protocol) Frame 24 (182 bytes on wire, 182 bytes captured) Protocols in frame: eth:ip:tcp:gist Internet Protocol, Src Addr: 10.1.1.7 (10.1.1.7), Dst Addr: 10.1.1.5 (10.1.1.5) Transmission Control Protocol, Src Port: 32000 (32000), Dst Port: 42338 (42338), Seq: 1, Ack: 257, Len: 116 General Internet Signaling Transport NAT/FW NSLP (NSIS Signaling Layer Protocol) Message Type: RESPONSE (0x04) Regards, Sergio

3 4

NATFW createPinhole comments
by sergiole＠tml.hut.fi 18 Dec '06

18 Dec '06

Hi, Comments about NSLP FW Below I include some comments, I am not asking for an answer right now, they are just to let you know my opinion about the current implementation and future considerations. 1) Time ago I stated that i did not agree with the behavior of FwApi::createPinhole() for ruleaction = allow / deny. (file natfw\api\FwApi.cpp) See the thread [Nsis_imp] Comments/parameters in NSLP NATFW 0.5.0-dev https://user.informatik.uni-goettingen.de/pipermail/nsis_imp/2006-November/… In fact your code reflects exactly the logic explained in draft-ietf-nsis-nslp-natfw-13.txt, chapter 4.2.3 Extended Flow Information Object (EFI). There is nothing wrong with the above. But the behavior stated in 4.2.3 EFI Object is too "protocolar"; i.e. it lacks the fact that by default an allow-all / deny-all policy will be dominating the environment. (It is like a digital tri-state logic:) Then if the default environmental policy is allow-all, in practice, I understand that the behavior will be: - With deny policy in the EFI : Add a DENY rule - With allow policy in the EFI : Remove the previous DENY rule And vice-versa. (See more details in the above mentioned thread) I do not have time to discuss about it, I will show you later my implementation so you can reconsider this issue in the future. 2) About EFI Object and sub_ports field. sub_ports field is a number that is added to the port number to define a range of ports. In draft-ietf-nsis-nslp-natfw-13.txt the draft states that sub_ports must not be other value than 0 and 1. Nevertheless it could be handy to use any number and then use it to implement a port range in iptables when crating a FW rule.... 3) I am using a different approach to the implementation of the createPinhole(). In 1) I mentioned my thoughts about the case of allow / deny. Now, another problem that I found is the following: I have a deny-all (environment) policy in iptables FORWARD, then I use NSIS NATFW to enable the connections that I need (createPinhole-ALLOW) to stablish through the FW. I do not have a complete understanding of the protocol, but in my opinion this task it is not limited to use one call to Iptables. Suppose the scenario below DS NI NF (FW) NR 10.1.1.5 10.1.1.7 / 10.1.2.7 10.1.2.11 . . . . . . .---------CREATE---------->. . . . . . .---------CREATE---------->. . . . . .<-------RESPONSE----------. .<-------RESPONSE----------. . . . . Suppose that I need to enable a connection from 10.1.1.5 -port 5000 to 10.1.2.11-port 80 (Remember that my default policy is deny-all.) then at the FW I need NOT 1 but 2 rules !! , i.e.: Rule 1) Allow traffic from 10.1.1.5 -port 5000 to 10.1.2.11-port 80 and Rule 2) Allow traffic from 10.1.2.11-port 80 to 10.1.1.5 -port 5000 Otherwise (with only 1 rule) the FW will filter the traffic in one or other direction. Do you agree? Comments? My question is : 1) Should I use 1 time nsis-natfw and open the traffic for both sides (i.e. 2 calls to Iptables in createPinhole())? or 2) Should I use 2 times nsis-natfw and open the traffic for one direction per execution? (I think that the the correct answer is 1, otherwise, how should be the MRI in case 2...) Regards, Sergio

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Nsis_Imp December 2006