[c-nsp] [Fwd: FWSM 3.1 and Servers with redundant cards]

[Patrick McEvilly]

The source IP does not changing in the return flow, only the interface
the packet returns on, in your case its returning on DMZ_1, not DMZ_2.

>From your logs you can see the IP is still 192.168.2.1.

 Deny TCP (no connection) from 192.168.2.1/23 to 10.10.10.140/9244 flags
SYN ACK  on interface DMZ_1




varaillon wrote:
> Thank you for your replies!
> 
> The problem is not so much the asymmetric of the traffic but more the change
> of IP addresses source in the return flow:
> 
> [IP_src:10.10.10.1,IP_dst:20.20.20.2]----TCP/SYN---->FWSM----->20.20.20.2
> 
> X--FWSM<---TCP/SYN/ACK----[IP_src: 20.20.20.1,IP_dst: 10.10.10.1]
> 
> The ASA algorithm checks the validity of the return flow based on:
> -Src IP
> -Src Port
> -Dest IP
> -Dest Port
> -Translation
> 
> In my case the IP source/destination are not matching so the return flow is
> dropped.
> 
> To go back to the advised command:
> 
> Given that I have only one FWSM, could this "asr-group" command work for me?
> 
> Cisco says that this command:
> "causes incoming packets to be re-classified with the interface of the same
> asr-group if a flow with the incoming interface cannot be found."
> 
> The above sounds good, but Cisco adds:
> "If re-classification finds a flow with another interface, and the
> associated context is in standby state, then the packet is forwarded to the
> active unit for processing."
> 
> In my case, since I have only one FWSM, the flow will never be associated
> with a context in standby state, so I suspect that the re-classification
> will not occur, and the packets will be dropped.
> 
> Am I right? Or do I miss something here?
> 
> Thanks
> 
> Christophe
> 
> 
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Patrick McEvilly
> Sent: Saturday, September 01, 2007 4:06 PM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] [Fwd: FWSM 3.1 and Servers with redundant cards]
> 
> 
> 
> The FWSM supports asymmetric traffic using the asr-group configuration.
> I believe this will do what you want it to do.
> Patrick
> 
>>From the docs.
> 
> In some situations, return traffic for a session may be routed through a
> different interface than it
> originated from. In failover configurations, return traffic for a
> connection that originated on one unit may
> return through the peer unit. This most commonly occurs when two
> interfaces on a single FWSM, or two
> FWSMs in a failover pair, are connected to different service providers
> and the outbound connection does
> not use a NAT address. By default, the FWSM drops the return traffic
> because there is no connection
> information for the traffic.
> You can prevent the return traffic from being dropped using the
> asr-group command on interfaces where
> this is likely to occur. When an interface configured with the asr-group
> command receives a packet for
> which it has no session information, it checks the session information
> for the other interfaces that are in
> the same group.
> Note In failover configurations, you must enable Stateful Failover for
> session information to be passed from
> the standby unit or failover group to the active unit or failover group.
> If it does not find a match, the packet is dropped. If it finds a match,
> then one of the following actions
> occurs:
> . If the incoming traffic originated on a peer unit in a failover
> configuration, some or all of the layer
> 2 header is rewritten and the packet is redirected to the other unit.
> This redirection continues as long
> as the session is active.
> . If the incoming traffic originated on a different interface on the
> same unit, some or all of the layer
> 2 header is rewritten and the packet is re-injected into the stream.
> Note Using the asr-group command to configure asymmetric routing support
> is more secure than using the
> static command with the nailed option.
> 
> Enter the following commands to add an interface to an asymmetric
> routing group. Stateful Failover
> must be enabled for asymmetric routing support to function properly
> between units in failover
> configurations.
> hostname/ctx1(config)# interface if
> hostname/ctx1(config-if)# asr-group num
> Valid values for num range from 1 to 32. You need to enter the command
> for each interface that will
> participate in the ASR group. You can view the number of ASR packets
> transmitted, received, or dropped
> by an interface using the show interface detail command.
> You can create up to 32 ASR groups and assign a maximum of 8 interfaces
> to each group.
> Note The upstream and downstream routers must use one MAC address per
> VLAN and have different MAC
> addresses for different VLANs to allow for the redirection of packets
> from a standby unit to an active
> unit in failover configurations.
> 
> 
> 
> Hi,
> 
> 
> For redundancy reasons, we have a server with two network cards.
> 
> Each card belongs to a subnet and each subnet to a different DMZ.
> 
> The server has two default routes with different metrics, where the prefered
> default route is in the DMZ_1.
> 
> 
> +--------+-card_1--192.168.1.1/24----DMZ_1--+--------+
> | SERVER |                                  |  FWSM  |---OUTSIDE
> +--------+-card_2--192.168.2.1/24----DMZ_2--+--------+
> 
> 
> The problem is that when we telnet from the outside to the ip destination
> 192.168.2.1, the server replies using the ip source 192.168.1.1.
> 
> So the FWSM blocs, as it should, the SYN/ACK from the server:
> 
> %FWSM-6-302013:
> Built inbound TCP connection 146242008855220280
> for OUTSIDE:10.10.10.140/9244 (10.10.10.140/9244)
> to DMZ_2:192.168.2.1/23 (192.168.2.1/23)
> 
> %FWSM-6-106015:
> Deny TCP (no connection)
> from 192.168.2.1/23 to 10.10.10.140/9244
> flags SYN ACK  on interface DMZ_1
> 
> Given that we have one FWSM (so no exchange of states), is there anyway to
> overcome that issue from the FWSM?
> 
> Would it help to bring each DMZ in its own context?
> 
> Any comment will be welcomed.
> 
> Thank you.
> 
> 
> Christophe
> 
> 
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 
> 
> __________ NOD32 2498 (20070902) Information __________
> 
> This message was checked by NOD32 antivirus system.
> http://www.eset.com
>